Job Requisition Software: Approve Roles Before You Post

What is a job requisition, and what does requisition software do?

A requisition is the formal request to open a role, complete with the reason it exists and the money behind it. The software gives that request an identity and a route. In Pitch N Hire it lives under Hiring Pipeline, and the list shows the role with its department, a requisition ID, the status, the workflow it is travelling through, the priority, the hiring manager and the deadline. Two tabs split the view: everything, and the ones waiting on approvals. Status is the load-bearing field. A request is in review, approved, rejected, on hold, or flagged as requiring more, which means approver information is missing. That vocabulary sounds bureaucratic until you have eleven roles in flight and a finance partner asking which of them the company actually committed to. This is the front door to the applicant tracking system, not a duplicate of it.

Why do recruiters end up working roles nobody approved?

Because the request arrives as a message. A founder mentions a role in a standup, a manager forwards a job description, and a recruiter who wants to be helpful starts sourcing on Monday. Three weeks later the budget conversation happens, the role is deferred, and the pipeline of people already spoken to has to be told something. Nobody behaved badly. There was simply no artefact between wanting a person and hiring one. A requisition is that artefact. It forces four questions before any work starts: how many openings, by when, at what budget, and why this role now. Answering them takes a hiring manager twenty minutes and saves a recruiter a fortnight. It also gives you something to count later, because approved requisitions per quarter is a number your leadership can plan against and a message in a chat thread is not.

What belongs on a requisition form?

Enough for an approver to decide without a meeting. Creation runs as five steps. First you choose the path: open a new position from scratch, link to an existing job to reuse an approved profile, or send a request to a hiring manager. Then role details, covering title, department and the core of the position. Then hiring details, which is where openings, priority level and the target deadline go. Then compensation, as a budget or a salary range. Then review and submit. The record itself carries more than the form: a job description, a business justification and notes for the approver, alongside required experience, location and an expiry date. The justification field is the one teams skip and the one approvers read first. Write it for the person paying, not for the recruiter. Everything downstream, including job posting software, inherits these fields.

How should an approval workflow be structured?

As a named sequence, not a group email. A workflow in Pitch N Hire has a name and an ordered set of steps, and each step names a reviewer with their email and the permission they hold. Reviewers get either read access, which is view only, or write access, which lets them edit. Steps run in order, and each reviewer gets an email when their turn arrives rather than at the start, so nobody approves something a colleague later changes. Keep chains short. Three considered approvers beat seven who assume somebody else read it, and every extra step is another day of latency between a manager wanting a person and a recruiter being allowed to look. Match the permission to the role: a finance approver usually needs to read and decide, while the hiring manager who owns the requirement may genuinely need to edit.

How do you get input from people who are not in the system?

Send the request out rather than issuing another licence. A hiring manager who touches recruitment twice a year does not need a seat, but they do need to answer a question about experience levels or confirm the deadline. The request action takes their email address and sends a secure link. What comes back is not a silent edit. Their input arrives as proposed changes with old and new values shown side by side, so a maximum experience moving from ten to twenty is visible as a change somebody made, and the recruiter accepts or ignores it. The requisition view keeps a shared-with panel listing who received a link and its status. That pattern is worth copying anywhere in hiring: let outsiders contribute through a scoped link with an expiry rather than through an account nobody remembers to remove. The record stays intact and the licence count stays honest.

What goes wrong with requisition processes?

Requisitions get treated as paperwork and behave accordingly. Duplicates are the most common failure, where two managers request overlapping roles because neither could see the other request, which the requisition ID and shared list solve immediately. The second is the reopened rejection: a role is turned down, a manager asks again a month later, and it quietly restarts with no memory of why it was refused. Rejected requests should not silently reopen. The third is the expired requisition, still open in the system while the budget it referenced belongs to last quarter, which is why an expiry date sits on the record. The fourth is the approval chain that grew by accretion until seven people were required, at which point nobody reads carefully because everyone assumes somebody upstream did. Prune it. Read your recruitment metrics by requisition, not by job advert.

How does an approved requisition become a live role?

It hands over its own fields. The title, department, openings, salary range, location and experience requirement were all agreed by the approvers, so the job advert should be assembled from them rather than rewritten from memory. Only approved requisitions should be posted, and enforcing that single rule removes most of the arguments a hiring team has about scope. The requisition then keeps working after the advert goes live: it holds the hiring team, showing which recruiter and which hiring manager own it, and it carries the deadline everybody is measured against. Sort the list by deadline or priority and you have a genuine workload view of the quarter. That view is what a hiring plan is actually made of. When you want the reporting layer on top, that is recruitment analytics software, and the operating pattern behind all of it is recruitment management.

Requisition statuses and what each one blocks