Automation & Workflows

Automation exists for one specific reason: some recruiting decisions are repetitive enough that the team should not have to restate them manually for every candidate. When the same threshold or next-step rule is applied over and over, human effort is better used on judgment, not repetition.

In practice, automation helps teams solve three operational problems at once. It reduces queue handling time, enforces consistency across recruiters, and prevents late or forgotten follow-up actions once candidates hit a known threshold. The feature is intentionally job-scoped so every role can have its own decision logic without forcing the same automation onto unrelated hiring motions.

The current recruiter-facing automation surface is score-led. That means you define a candidate signal, compare it against a threshold, and tell Ovii what to do next. In the Simple Builder, rules are structured as `When` a score meets a condition, `Then` perform an action after a selected delay.

The available trigger fields are intentionally narrow. Resume Match Score is always available. Assessment Score and Async Video Score only become available when those stages are active in the pipeline. This keeps recruiters from building automation against signals that the job cannot actually produce.

The rule actions are also intentionally constrained to real operating outcomes: send a rejection email, send an assessment invitation, send an async video invitation, or move the candidate to another stage. This is a deliberate product choice. The point is not infinite automation flexibility. The point is dependable hiring operations.

Note

The underlying workflow engine also supports stage-entry triggers, but the current recruiter builders in this tab are designed primarily around score-based rule creation. That keeps the day-to-day configuration surface simpler and easier to govern.

Automation is intentionally not the first thing you configure on a job. Ovii requires the pipeline and feedback form to be approved before the builder becomes fully usable, because automation should operate on a stable hiring design rather than on half-finished workflow definitions.

There is an additional readiness check for assessment and async video paths. If your pipeline includes Assessment or Async Video, but the job has no questions configured for that channel, the automation builder blocks the affected rules. This prevents a rule from sending candidates into a stage that has no real content behind it.

The Simple Builder is the most direct way to create operational rules. It presents automation in a compact sentence form: choose the score signal, choose the comparison operator, enter the threshold, choose the action, and define the delay.

This design matters because recruiters usually think in hiring policy statements, not in programming constructs. A good automation rule should read like a sentence the team could defend out loud. For example: if Resume Match Score is greater than or equal to 75, send an assessment invitation after 2 days.

The action matters more than the trigger. The same score threshold can mean very different things depending on what the system does next. That is why action choice should reflect candidate experience, recruiter workflow, and the confidence level of the signal you are using.

Delay is equally important. Immediate automation is helpful when the action is low-risk and expected, but some teams intentionally delay messages so a recruiter can sanity-check edge cases before the scheduled communication goes out. Ovii supports a test delay and a range of day-based delays for exactly this reason.

Note

A delay value of 0 is treated as a test/immediate path. In the current system this is represented as a short test-style delay rather than a long waiting period.

The Visual Builder presents the same logic in a node-based canvas. Recruiters can drag trigger, action, and delay nodes onto the canvas, connect them, and save them as workflow rules. This is useful when the team understands the automation policy better as a flow than as a sentence.

Even so, the visual builder is not a separate execution engine. It saves into the same workflow-rule model used by the simple builder. That means the same validations and backend guardrails still apply.

Automation is not limited to future candidates only. When a new rule is created, the backend immediately evaluates eligible candidates already attached to that job. That is an important enterprise behavior because it prevents recruiters from assuming automation only applies prospectively.

The engine also checks new candidates against existing active rules. For delayed email actions, the actual send is handled by the scheduled workflow processor. For immediate non-email actions such as stage movement, the action can be executed directly when the condition is met.

This matters operationally because automation in Ovii is not only event-driven. It is also reconciliation-driven. The system actively tries to catch candidates or rules that may have been missed earlier, which makes the automation layer more resilient than a one-time trigger model.

Ovii deliberately restricts automation in places where candidate harm, reporting drift, or workflow contradictions would otherwise become easy. These constraints are not product rough edges. They are governance controls.

The most important principle is that automation should be fast, but it should also remain explainable. If a recruiter cannot describe why a rule exists, when it fires, and how it can be audited, that rule is not mature enough for production use.