"When X happens, do Y" — automate the boring pipeline moves.
Pipeline automations let you encode the rules you'd enforce manually — "if a candidate scores 85%+ on any open job, auto-shortlist them" or "if a candidate has sat in the pipeline 7+ days with no outbound message, notify the team." Every fire is audited and deduped per-(rule, candidate) pair so you never get duplicate actions.
How a rule is shaped
Two parts. Trigger picks the candidates the rule cares about. Actionsays what to do with them. Today's catalogue:
Triggers
- score_threshold — candidate has any match with score ≥ N% (default 85). Optionally restricted to specific job IDs.
- stale_candidate — candidate in one of the configured statuses (default: new / shortlisted / interview_scheduled) with no outbound email in N days (default 7).
Actions
- set_status— update the candidate's pipeline status to one you pick. Common pairing: score_threshold → set_status "shortlisted".
- notify — push an in-app notification to every workspace admin with a title + body you supply. Pairs well with stale_candidate.
Walk-through: auto-shortlist strong matches
- Open /automations → click + New rule.
- Name it something memorable: "Auto-shortlist strong matches".
- Trigger: score_threshold, min score 85.
- Action: set_status → shortlisted.
- Save. The 5-min scheduler tick will start evaluating it.
Dedupe + safety caps
Per-tick safety cap: 25 candidates per rule per evaluation. A misconfigured rule can't accidentally fan out thousands of status changes before you notice — worst case it burns through 25 every 5 minutes.
How to test a rule before it goes live
On the rule row, hit Run now. The engine evaluates every active rule (your fresh one included) and reports { rulesEvaluated, firesTotal }. Check /activity to see exactly which candidates were touched and what changed.
Pausing without deleting
Toggle the Pausebutton on the rule. The fireLog is preserved, so when you flip it back to active you don't re-fire on candidates that were already actioned.