How Ovii Keeps Candidate Source, Stage, and Status Separate

Recruiters do not ask only one question about a candidate. They ask where this person came from, whether they are still in intake or already in the active pipeline, whether a test or async interview is underway, whether interviewers have been assigned, whether feedback is still pending, and whether the person was rejected with a traceable reason. A single status label cannot carry all of that cleanly.

Ovii’s candidate flow is more trustworthy because it does not force those meanings into one bucket. The row in the Candidates table is assembled from multiple signals that remain separate underneath: `resumeSource`, the current job status definition, special assessment or video progress, interviewer assignments, feedback submissions, and recommendation data for the current round.

That separation is not over-modeling. It is what keeps the recruiter-facing list understandable even when a role mixes recruiter uploads, referrals, assessments, async video, manual interviews, and final disposition.

Ovii treats provenance, workflow location, live stage condition, and evaluation outcome as different signals because recruiters need all of them to stay true at the same time.

One of the clearest signals in the code is that resume source is preserved explicitly. The recruiter table maps concrete intake types such as `RECRUITER_UPLOAD`, `RECRUITER_BULK_UPLOAD`, `JOB_BOARD_APPLICATION`, `BRANDED_CAREER_BOARD`, `EMPLOYEE_REFERRAL`, `VENDOR_UPLOAD`, `TPO_STUDENT`, and `CANDIDATE_UPLOAD` into readable labels such as Recruiter, JobBoard, Career Board, Referral, Vendor, Student, and Candidate.

That matters because source is not just decorative attribution. It tells the team which channel produced the candidate, which workflows created the profile, and how later pipeline analytics should be interpreted. A referred candidate and a recruiter-uploaded candidate may end up in the same interview round, but they did not enter the role the same way.

Ovii keeps that provenance available even after the candidate moves forward. The row can still say Referral or Vendor while the person is already deep in assessment, async video, or a manual interview round. That is exactly the right behavior if the product wants to preserve channel truth instead of overwriting it with workflow progress.

The frontend and backend both make an important distinction between storing intake codes and presenting them cleanly. In the candidate table, the helper that derives stage labels recognizes intake-style codes such as `APPLIED`, `UPLOADED`, `REFERRED`, and `VENDOR` and normalizes them into the cleaner recruiter-facing label `Initialized`.

That is a subtle but smart decision. Internally, the system still knows whether the row came from application, upload, referral, or vendor intake. But the visible stage label stays calmer for recruiters, because those codes are all part of the same early operating layer rather than different evaluation checkpoints.

The same helper also gives special treatment to operational stages such as `ASSESSMENT` and `VIDEO_SCREEN`, mapping them to readable labels like Assessment and Async Video. So the product is not hiding real workflow steps. It is separating raw intake codes from the actual stage language recruiters use while moving candidates through the role.

Ovii normalizes multiple early intake codes into `Initialized` for readability, while still preserving the original source underneath for provenance and reporting.

This is the part many products blur together. In Ovii, stage answers the question “where is this candidate in the workflow?” Status answers the question “what is happening inside that stage right now?” Those are not the same thing, and the row logic reflects that distinction clearly.

For assessment and async video steps, the backend computes stage-local progress labels separately from the stage itself. Assessment status can show states such as Invited, Started, Completed, Evaluating, or Expired. Async video does the same for the video interview path. The table still keeps the stage label as Assessment or Async Video while using a different field to show live progress inside that stage.

Manual interview rounds behave differently again. The candidate row checks whether the current stage looks like a screening or interview round, then uses `feedbackAssignedCount`, `latestRecommendation`, and `hasPendingFeedback` to decide what the recruiter should see. If nobody is assigned, the row shows Not Assigned. If interviewers are assigned but no stage recommendation is available yet, it shows Pending. If feedback has been submitted for the current stage, the row can surface that recommendation directly.

One of the more thoughtful implementation details sits in how the candidate row handles interview feedback. The backend does not simply grab the latest feedback entry overall. It filters feedback down to the current stage label, then takes the earliest submitted recommendation for that round when filling `latestRecommendation` for the table.

That means the row gets a stable visible recommendation instead of constantly changing as more interviewers submit. At the same time, the backend still checks whether multiple different recommendations exist within the current stage. If they do, it exposes `hasRecommendationConflict` and the set of conflicting recommendations separately.

That is a very good compromise for recruiter operations. The table stays readable, but disagreement is not erased. Recruiters can see one stable status in the list while still being warned that the underlying panel is not fully aligned.

Ovii uses a stable stage-level recommendation for the list view, but it still flags disagreement explicitly instead of pretending the panel is already aligned.

Ovii also keeps ownership separate from stage itself. Assigning interviewers is not the same as moving a candidate. The stage-change modal lets recruiters move the candidate and optionally assign interviewers, but the assignment is persisted independently in the `CandidateInterviewer` layer for a specific candidate and stage.

The backend service groups assignments by stage label when the recruiter opens the candidate drawer, and the assignment API stores normalized email addresses against the chosen stage. Duplicate candidate-stage-email assignments are skipped instead of written repeatedly. That means the system can later answer a very precise question: who is supposed to act on this candidate in this round?

This is especially useful because the product allows same-stage assignment. A recruiter does not have to invent a fake move just to attach interviewers. If the candidate is already in the correct round, the recruiter can keep the stage unchanged and use the modal or feedback surface to add stage-specific ownership.

Another trust-building choice in this flow is that feedback and movement are related but not fused. The feedback form records structured evidence for the relevant round, including support for privileged users, regular interviewers, and even late feedback when the candidate has already moved past the assigned stage.

But submitting feedback does not silently rewrite the pipeline. In the current flow, the recruiter still owns the stage transition. The form can show recommendation outcomes and refresh the candidate state, yet late feedback explicitly avoids changing the candidate stage if the candidate has already moved onward.

This is the right operating model for real hiring teams. Interview evidence should be recorded as evidence. Movement should remain an explicit recruiter decision informed by that evidence, not an automatic side effect every time someone clicks submit.

Ovii lets feedback shape the recruiter-facing signal without turning every form submission into an automatic stage transition.

The stage-change modal does more than collect a destination. When it opens, it fetches the latest job statuses, filters down to active pipeline stages, excludes rejected, sorts by pipeline order, and validates the move against the candidate’s current stage. Moving backward is blocked. Staying in the same stage is allowed, because that is useful for assignment-only updates.

There is another good layer of safety in the candidate feedback surface. If a candidate is still in intake, the UI checks whether the job pipeline is approved and whether the feedback template is approved. If the job contains active Assessment or Async Video stages, the UI also checks whether the required question sets actually exist before allowing recruiters to move people into those steps.

That keeps the workflow honest. A recruiter cannot meaningfully say a candidate is now in assessment if the role has no assessment questions configured. The same goes for async video. Ovii pushes the team toward operational readiness before it allows candidate progression into those stages.

Rejection is another place where Ovii keeps state and evidence aligned. When a recruiter rejects a candidate, the backend ensures a `REJECTED` status exists for that job, updates the job application, syncs referral state if the candidate came through the referral path, and publishes the status change event for downstream listeners.

If the recruiter includes a rejection comment, the system also saves that reason as interview feedback. The round is recorded as Rejection, the recommendation is stored as `NO_HIRE`, the rejection reason is placed into the feedback payload, and private visibility is set to HR-only.

That design matters because rejection should not disappear into an action log. In a governed workflow, the disposition itself belongs to the pipeline, but the reason belongs to the evidence trail. Ovii keeps both.

A rejection in Ovii is not just a status flip. It can also become structured HR-visible feedback attached to the same candidate and job.

Keeping candidate movement manual does not mean the rest of the system is disconnected. When the application status is updated, the backend still enforces entitlements for premium stages such as assessment and video, syncs referral status when applicable, fires stage-based workflow rules, and publishes an `ApplicationStatusUpdatedEvent` for other listeners.

That is an important nuance in how Ovii is built. Recruiters remain in charge of the decisive move, but the platform still reacts like a workflow system once that move happens. Operational automation and downstream listeners stay attached to the application record without taking control away from the recruiter.

This is a better story than saying candidate flow is either manual or automated. In Ovii, the decisive progression is manual, while the surrounding infrastructure remains event-aware, auditable, and capable of invoking the next governed action.

The original help doc is useful because it explains where to click. The stronger product story is why the candidate surface behaves the way it does. Ovii is not strongest when it is described as a generic candidate management screen. It is strongest when it is described as a governed workflow view that keeps provenance, stage, live status, ownership, and evidence from bleeding into each other.

That separation creates recruiter trust. The row stays readable. Channel truth survives later stages. Automated steps can show progress without replacing the workflow stage. Interview rounds can show ownership and recommendation without silently moving candidates. Rejection stays tied to evidence. Manual progression can still trigger downstream workflows and events.

Those are not cosmetic choices. They are the kind of product decisions that make a hiring system usable when a role is live and multiple recruiters, interviewers, channels, and automation paths are all active at once.