Job Requisition: A Recruiter Workflow and Handoff Guide

A job requisition gives a recruiting request a durable identity. It tells the hiring team which opening is active, who owns the request, what state it is in, and which documents belong to it. For a recruiter, that operating record matters because a title in a message or a detached job description cannot reliably answer whether the request is approved, open, paused, revised, or closed.

The exact workflow differs by organization and recruiting system. Dayforce's June 2026 recruiting documentation says its job requisition form is used to initiate a request to fill jobs and may pass through workflow stages before recruiters work on the role. ServiceNow's March 2026 documentation shows a hiring manager requesting an opening, saving or submitting the request, and the recruiter seeing the resulting open request in the recruitment workspace. These are product-specific examples, not a universal state model. They demonstrate why the requisition is best treated as an operating record rather than another copy of the job description.

This guide covers the requisition workflow itself: identity, ownership, state, recruiter handoff, linked records, changes, and closeout. Role calibration belongs in intake, job-description quality belongs in the job-description workflow, and candidate evidence belongs in screening.

Give every job requisition a stable identity

Create the requisition identifier as soon as the request becomes a record. Keep that identifier stable even when the title, hiring manager, or opening details change. Every related artifact should point back to it, including the active job description, intake record, posting, candidate pool, interview plan, and eventual closeout note.

A practical requisition header contains:

• Requisition ID: the permanent reference used across systems and handoffs.
• Working title: the current internal label, with prior labels preserved in the change history.
• Request type: the team's own classification for a newly created role, a replacement, or another approved opening type.
• Opening count: how many active openings this record represents.
• Work setup: the approved location and working arrangement used by the recruiter.
• Owners: the hiring manager, assigned recruiter, and current workflow owner.
• Key dates: submission, latest decision, recruiting-open date, target start window, and close date when applicable.
• Current state: one explicit value from the team's requisition state model.

Keep this header operational. It should identify the request and its route through recruiting. The detailed role discussion can remain in a linked document without forcing every system to hold a competing version.

Separate the requisition from adjacent records

In a clean operating model, each record has one job. The requisition tracks the request to recruit. The job description explains the work to potential candidates. A posting is one publication of that description on a particular channel. A candidate record tracks one person's progress and evidence. An interview plan tells interviewers what to examine.

The distinction prevents state errors. Closing one posting does not necessarily close the requisition. Revising a job description does not automatically change the approved opening count. Moving a candidate through the recruitment pipeline does not change whether the requisition itself is open for additional candidates.

Link the records rather than copying them blindly. The requisition should show which job-description version is active, but the full candidate-facing text should have one maintained home. Candidate ratings should reference the requisition and its role-definition version, but they should not be stored as requisition fields.

Use a requisition state model the team can observe

Adopt state names that match the systems the team actually uses. A workable sequence might distinguish draft, submitted, needs revision, approved, open for recruiting, paused, filled, withdrawn, and closed. Your sequence may differ. The important part is that every state has a defined entry event, permitted next states, owner, and visible timestamp.

“Approved” and “open for recruiting” deserve separate meanings when an approved request still needs recruiter intake or a final document before search begins. “Paused” should name who can reopen the request and what remains frozen. “Filled” can record that the opening target has been reached, while “closed” marks the end of active workflow. Avoid one generic status that requires recruiters to reconstruct meaning from messages.

For each state, document four things:

1. the event that enters the state;
2. the person responsible while it is active;
3. the fields or linked records required to leave it; and
4. the next states the workflow allows.

This is a role-level state machine, not a candidate pipeline. Keeping the two separate lets a recruiter pause new sourcing while still completing an already scheduled candidate conversation, if that is the team's chosen workflow.

Make the recruiter handoff explicit

The recruiter should receive the requisition as an assigned work item, not discover it from a forwarded document. At handoff, verify the requisition ID, active state, opening count, work setup, hiring manager, assigned recruiter, target dates, and active job-description link. Any unresolved field needs an owner and a due point.

The handoff should also say what happens next. If role calibration is still required, schedule the recruiting intake and keep the requisition out of the recruiting-open state until the agreed readiness rule is met. If the job description needs revision, route it through the job-description checklist rather than turning the requisition into another editing surface.

Record recruiter acceptance separately from request approval. Approval says the request may proceed under the organization's process. Recruiter acceptance confirms who owns the active recruiting work and whether the handoff contains what that person needs.

Map the requisition across systems

A request may begin in one workspace and continue in an applicant tracking system. The requisition ID should travel with it. Define which system is authoritative for state, opening count, owner, job-description version, and closeout. If two systems can edit the same field, decide how conflicts are surfaced and who resolves them.

Use a small field map:

• source field and destination field;
• authoritative system;
• allowed editor;
• sync direction;
• last verified timestamp; and
• exception owner.

Do not infer that a successful transfer means the values are correct. Check the first created requisition after a mapping change, and preserve the source value when a destination field rejects or shortens it. A recruiter should be able to see whether the record is current before acting on it.

Control changes after recruiting opens

Changes to the opening count, work setup, owner, target dates, state, or linked documents can alter recruiter work. Record each material change with the previous value, new value, requester, approver, timestamp, and operational effect. Send the assigned recruiter a clear change summary rather than relying on them to notice a field edit.

Classify the effect. An owner change may require a handoff but no candidate re-review. A location or working-arrangement change may require updated outreach and posting records. A changed job-description version may also alter screening criteria; when it does, return to intake and decide which candidates need review under the updated definition.

Do not overwrite the old value without history. The recruiter needs to explain which version governed sourcing and screening at each point, especially when active candidates entered the workflow before a material change.

Connect candidate evidence without mixing record types

Once screening begins, attach the requisition ID and active role-definition version to the candidate pool. The guide to screening candidates against a job description shows how to keep ratings tied to visible evidence and human review. Those candidate-level evaluations should remain separate from the requisition itself.

The requisition can summarize operational counts and link to the pool, but it should not become a second candidate tracker. One record answers “Is this recruiting request active, owned, and current?” The other answers “What evidence supports the review of this candidate?” Keeping those questions separate prevents a role-level change from silently rewriting a candidate decision.

Close the requisition deliberately

Define which event moves the requisition out of active recruiting. At closeout, record the final state, effective date, opening count resolved, remaining linked postings, active candidate handoffs, and owner of any follow-up. Stop new sourcing and publication actions through the normal workflow rather than leaving disconnected records active.

Preserve links to the active job-description version, intake record, and candidate pool so another recruiter can reconstruct the role workflow later. Closeout is a requisition action; it should not invent a new candidate outcome label or replace candidate statuses already recorded elsewhere.

Use AI for record checks, not workflow authority

AI can normalize incoming fields, compare two versions, flag a missing owner, detect an apparent mismatch between opening count and state, and draft a change summary. It can also group exceptions for a recruiter to review.

Every output remains provisional. A recruiter or hiring manager should verify it against the authoritative system, approve material changes, and retain responsibility for opening, pausing, or closing the requisition. AI should not create hidden state transitions, approve the request, alter candidate records, or decide who advances.

Job requisition workflow checklist

• Does the request have one stable requisition ID?
• Are title, request type, opening count, and work setup current?
• Are hiring manager, recruiter, and workflow owner named?
• Is the current state observable with a timestamp?
• Does each state have an entry event, owner, and allowed next step?
• Is recruiter acceptance separate from request approval?
• Does the requisition link to one active job-description version?
• Is an authoritative system named for every shared field?
• Do sync failures retain the source value and an exception owner?
• Are material changes recorded and sent to the recruiter?
• Are candidate evaluations stored outside the requisition?
• Does closeout stop active role workflows without duplicating candidate outcomes?
• Does a person own every requisition and candidate decision?

Make the requisition the operating spine of the role

A useful job requisition is not a longer job description or an early candidate scorecard. It is the operating spine of one recruiting request: stable identity, explicit state, clear owners, linked records, controlled changes, and deliberate closeout. When the recruiter can trust those fields, intake, publication, sourcing, and screening can each do their own job without rebuilding the role's status from scattered messages.