Recruitment and applications

Applicant tracking system domain modeling

When to use

When implementing or reviewing an ATS application pipeline, interview workflow, candidate relationship or recruitment permission model. Preserve the difference between a person, an application and a hiring decision.

Workflow

1. Inspect the installed ATS version, schema, API contracts, job configuration and current authorization code. Identify the system that owns each record and the organization's approved hiring workflow. Use synthetic or minimized examples; do not copy CVs and interview notes into broad diagnostics.
2. Model candidate, job/requisition and application separately. A candidate represents a person in the authorized organizational context; a job defines a hiring need; an application links that person to a particular job and its process. One candidate may have several simultaneous applications. Rejecting one application must not reject the person's other applications or overwrite a global candidate status.
3. Represent pipeline stages separately from application disposition. Record transitions as history with application ID, from/to state, actor, effective time, recorded time and reason. Include withdrawal, rejection, hire and reopening under the actual business rules. A reopened application keeps its earlier decision history and has a new transition; do not rewrite it to look continuously active. Distinguish correction of a mistaken event from a new business transition.
4. Define which related records are application-specific: interviews, scorecards, evaluations, offers and stage-specific tasks. Document any deliberately shared candidate data. Reusing an interview or transferring an application to another job needs explicit provenance and an approved process, not an incidental foreign-key update. Handle candidate merges with a preview and traceable mapping; matching names or email addresses alone do not establish identity.
5. Establish a capability matrix per organization and job. Recruiters need only the requisitions and actions assigned to them. An interviewer needs access to their scheduled interview and authorized evaluation fields, not automatically the entire candidate history, compensation data or other interviewers' notes. Apply these boundaries to list/search, direct record URLs, files, exports and background tasks as well as page controls.
6. Implement state transitions with concurrency checks and auditable authorization. Prevent two simultaneous updates from overwriting an interview or silently reversing a hiring decision. Preserve historical stage definitions when a job's pipeline changes, and make any migration mapping reviewable before moving active applications.

Evidence and verification

Deliver an entity/ownership map, application transition table and recruiter/interviewer access matrix based on the actual product. Exercise one candidate applying to two jobs, an application rejected then reopened, a job whose stages change, a withdrawn application and an interviewer removed from the panel.

Verify that stage moves affect only the target application, old decisions remain reconstructable, an interviewer cannot access another job's records, and stale or duplicated commands produce one intended transition. Distinguish internal state changes from actual invitations, rejection messages or offer delivery.

Boundaries

• Hiring decisions remain with authorized humans using approved, job-related criteria. Do not introduce automated candidate ranking or rejection based on sensitive attributes, inferred traits or proxies for them.
• Do not treat an integration account's technical permissions as permission to disclose candidate records to every recruiter.
• Do not send candidate messages, issue offers or change real application outcomes unless the user has authorized those actions.

Primary reference

Inspect the API version supported by the connected account before applying vendor-specific relationships or fields:

• https://harvestdocs.greenhouse.io/reference/get_v3-applications