How to set up ATS approval workflows for hiring requisitions

Hiring managers usually want the job open yesterday. HR, finance and leadership need to know the role is approved, budgeted, correctly levelled and safe to publish before recruiting starts.

An ATS approval workflow is the control layer that sits between “we need to hire” and “this job is live”. Done well, it keeps standard hiring moving and forces proper scrutiny only where risk is higher.

The mistake is treating approvals as a tick-box automation. They are not. They decide who can create a requisition, which fields must be completed, who signs off, what changes restart approval, and whether a role can move from request to open job.

What is an ATS approval workflow?

An ATS approval workflow is the routed process that turns a hiring request into an approved requisition, open job, or approved offer. It usually sits before job creation, job publishing and offer extension.

For requisitions, the workflow confirms whether the business is allowed to hire. That means headcount, department, cost centre, compensation range, location, hiring manager and justification are checked before recruiters spend time sourcing candidates.

The upside is control without a spreadsheet chase. The downside is that a badly designed approval flow slows every hire, including simple backfills that should take minutes to approve.

How are requisition, job and offer approvals different?

Requisition approval confirms the company should hire for the role. Job approval controls whether the job can be opened or published. Offer approval controls whether compensation and terms can be sent to a candidate.

Those three checks should not be merged into one vague sign-off. A finance approval for planned headcount is different from an approval to extend an above-range offer to a finalist.

Greenhouse is a useful example because its documentation separates job approvals and offer approvals. It also supports one-stage job approvals, where approval is needed to start recruiting, and two-stage approvals, where approval is needed to start recruiting and again to send an offer.

That structure is strong if you need governance around structured hiring. The catch is that Greenhouse is an enterprise product in ATSLab’s data, with a recorded starting price of around $6k and public pricing handled by custom quote.

What should your requisition form include?

Build the form around the decisions approvers actually need to make. If a field will not change approval, reporting, budget or compliance, question whether it belongs on the first version.

A practical requisition form should include job title, department, location, hiring manager, recruiter, employment type, backfill or net-new headcount, compensation range, job level, target start date, cost centre, business justification, remote or onsite status, and confidential-role flag.

That is enough for HR and finance to assess the request without turning the form into a survey. Add too much detail and hiring managers will guess, skip fields, or ask recruiters to fill it in for them.

Keep compensation fields structured where possible. A free-text salary note is easier to type, but it is harder to route, report on and use as a trigger for extra approval.

How should approval routing work?

Approval routing should follow the fields that change risk. The common triggers are department, office, country, location, salary band, job level, role type, replacement versus new headcount, and cost centre.

Greenhouse can configure job approvals by office, department, office plus department, or all jobs. It can also use specific users or role-based approvers using custom job fields.

Teamtailor is another clear example. Its requisition flows can be triggered by country, location, department, role, salary or additional fields, and its requisitions act as a mandatory form before a job can be created.

The upside of detailed routing is precision. The downside is maintenance: every reorganisation, new department, new office, or changed finance owner can break the logic if nobody owns the approval map.

Should approvals be sequential or parallel?

Use sequential approvals when one approver’s decision depends on another. Use parallel approvals when several people can review the same request at the same time.

A sequential flow works well for HR review before finance, or finance approval before an executive signs off an exception. It creates a clear order, but one absent approver can block the whole requisition.

A parallel flow works well when HR, finance and a department leader can all check their part independently. It is faster, but only if the system makes ownership clear and does not let everyone assume someone else will catch the issue.

Greenhouse supports requesting approvals all at once or in order. Workable describes requisition approvals in Hiring Plan as sequential, moving from one approval group to the next before the requisition can be opened.

How do you control edits, bypasses and notifications?

Define permissions before launch: who can create requisitions, who can submit them, who can approve them, and who can override the process. If bypass rights are vague, the workflow will be bypassed.

Lock sensitive fields after submission unless changes are intentional and logged. Compensation range, job level, headcount type, department and location should usually re-trigger approval if they change after sign-off.

Greenhouse says job detail changes can re-trigger job approval stage requests. That is the right principle: if the approved job is no longer the same job, the approval should not silently stand.

Notifications matter because approval workflows often fail in the gaps between people. Use email and in-app alerts where the ATS supports them, and add Slack or Microsoft Teams routing only if your stack can do it reliably.

Greenhouse has a My Approvals section and sends approval emails to approvers. That is useful for busy managers, but it still depends on clean ownership and sensible escalation rules.

What happens when a requisition is rejected?

A rejected requisition should return with a clear reason and a defined resubmission path. Without that, rejection becomes another way to create side-channel hiring requests.

Require rejection comments. Finance might reject because the role is outside plan, HR might reject because the level is wrong, and leadership might reject because the timing conflicts with a headcount freeze.

Teamtailor allows approvers to approve or deny requisitions, and denied requisitions can be resubmitted. That resubmission loop is useful, but you still need to decide whether the request restarts the full workflow or returns to the rejecting approver.

Keep the approval history. Auditability is the point of the workflow, especially for sensitive roles, compensation exceptions and markets with stricter employment controls.

How do Greenhouse, Lever and BambooHR compare for approval workflows?

Greenhouse is the structured-hiring governance example. It supports job and offer approvals, office and department routing, role-based approvers, and both all-at-once and in-order approval requests.

That makes Greenhouse a strong fit if approval design is tied to structured hiring and enterprise controls. The trade-off is cost and complexity: ATSLab records Greenhouse from around $6k, and its public pricing page lists Core, Plus and Pro plans without a public dollar figure.

Lever is the ATS plus CRM example. LeverTRM advertises customisable approval chains and offer letters, and Lever documentation references requisition API support for pushing requisitions from an HRIS into Lever.

Lever also describes Dynamic Offer Approvals that can route by role, team, department, location and requisition criteria, with up to five conditions per approval step. The caution is packaging: Lever pricing is available on request, ATSLab records it from around $4k, and approval capabilities may vary by plan and configuration.

BambooHR is the HRIS-first small-business example. It includes Workflows & Approvals across Core, Pro and Elite, and describes custom approval forms with routing by division, department and location.

BambooHR is attractive if your approvals sit closer to HR operations than high-volume recruiting. The limitation is volume: its public pricing page lists ATS job-opening limits of 5 on Core, 25 on Pro and 50 on Elite, so it needs checking before you run large hiring plans through it.

What approval workflow template should you start with?

Small teams should start with a light workflow: hiring manager submits, HR approves, and finance approves only if the role is outside the headcount plan or compensation range.

That keeps straightforward backfills moving. The limitation is that it relies on a current hiring plan; if the plan is vague, finance will end up reviewing almost everything.

Scaling companies usually need a stricter chain: hiring manager submits, department leader approves, finance approves, HR or talent ops checks structure, and executive approval applies only to exceptions.

That design works if department leaders own headcount and talent ops owns process quality. It becomes slow if every senior leader insists on approving every role, including junior replacements already in budget.

Enterprises should route by business unit, location, salary band, job level and confidential status, with separate offer approvals for compensation and terms. The benefit is control at scale, but it needs a named owner to maintain rules as the organisation changes.

What should you test and measure after launch?

Test the workflow with real scenarios before it goes live. Use a simple backfill inside budget, a net-new role above a salary threshold, and a confidential executive role.

For each scenario, check the approver list, approval order, rejection comments, resubmission path, edit permissions, notifications and audit trail. Do not rely on a happy-path test where every field is perfect.

After launch, track approval cycle time by department, location and approver. Also track rejection rate, common rejection reasons, ageing approvals by owner, roles opened with missing information, and post-submission edits that re-trigger approval.

The goal is not to make every approval strict. The best approval workflow is simple for standard roles and strict for exceptions.