Back to all case files

Case Files

Case #001: Designing an ATS Candidate Pipeline From First Principles

A practical system design breakdown of an applicant tracking candidate pipeline, from actors and states to audit logs and AI-first workflows.

Published
system designatsworkflowsaas

A candidate applied. HR says the profile was screened. The hiring manager says they never received it. The database says everyone is telling the truth.

Welcome to Case #001: the candidate pipeline mystery.

Direct answer: how should an ATS candidate pipeline be designed?

An ATS candidate pipeline should be modeled as an auditable workflow, not as one editable status field.

At minimum, it needs:

  • Actors with clear permissions
  • Valid state transitions
  • Ownership rules
  • Status history
  • Reason capture
  • Notifications
  • Audit logs
  • Human review for AI-assisted decisions

The current status matters, but the history explains what actually happened.

The common culprit: one status column

The naive design starts like this:

applications.status = "screened"

That looks fine until the product needs to answer practical questions:

  • Who changed the status?
  • Why was it changed?
  • Was the hiring manager notified?
  • Did the candidate apply to multiple jobs?
  • Did HR reject the candidate or move them back for review?
  • Can a manager override an HR decision?

A single status field stores the conclusion. It does not store the case notes.

The actors in the workflow

A basic ATS workflow usually includes:

  • Candidate
  • Recruiter or HR user
  • Hiring manager
  • Interviewer
  • Organization admin
  • System automation

Each actor can perform different actions at different stages. That means permissions are part of the workflow, not an afterthought.

The first-principles model

A hiring pipeline is a coordination system between people. It has data, but it is not only data storage.

The design needs to represent:

  • State: where the application is now
  • Event: what happened
  • Actor: who or what caused it
  • Reason: why it happened
  • Time: when it happened
  • Visibility: who can see it
  • Obligation: who must act next

This turns the pipeline from a dropdown into a system of record.

Practical states for version one

A simple pipeline can start with these states:

  • Applied
  • HR Screening
  • Sent to Manager
  • Manager Review
  • Interview
  • Offer
  • Hired
  • Rejected
  • Withdrawn

Do not add twenty stages because enterprise tools have twenty stages. Add a stage when it changes ownership, permissions, reporting, or user expectations.

A zero-cost implementation path

For an early SaaS product, start with:

  • applications table with the current state
  • application_events table for history
  • Application-level transition validation
  • Basic role checks
  • Email notifications for important handoffs
  • Admin-visible audit trail

This keeps the architecture understandable while preserving the information needed to debug disputes later.

AI-first extensions

AI can help the pipeline without replacing accountability:

  • Summarize resumes for recruiters
  • Draft screening notes
  • Suggest interview questions
  • Highlight missing candidate information
  • Explain why a candidate moved stages
  • Detect stale applications that need follow-up

AI should not silently reject candidates. The product should keep a human in the loop, record AI-generated suggestions, and distinguish suggestions from decisions.

Metrics worth tracking

Useful analytics include:

  • Time in each stage
  • Drop-off by stage
  • Manager response time
  • Source quality by job
  • Offer acceptance rate
  • Rejection reasons
  • AI suggestion acceptance rate

These metrics are only trustworthy if the workflow history is trustworthy.

Useful summary

The culprit was not the status field. The culprit was treating a human workflow like a simple dropdown.

Case closed: store the current state for speed, store events for truth, and design AI as an assistant with a paper trail.