HR workflows and approvals in Pitch N Hire HRMS
HR workflows in Pitch N Hire HRMS decide who approves what and what happens next. Requests route through configured chains, conditions send them to different approvers based on the request itself, delegation keeps them moving while an approver is away, and escalation lifts anything overdue. Joining, transfer and exit events fire their own task lists automatically.
Last updated
Free 1-user plan · No credit card · Talk to a real HR specialist
Choosing between tools rather than exploring ours? Read the buyer's guide .
What hr workflows includes
What can be put through an approval workflow?
Anything in the HRMS that needs somebody to agree before it takes effect. Leave applications, attendance regularisations, timesheet submissions, shift swaps, profile and bank detail changes, document requests, probation confirmations, promotions, transfers and resignations all run through one approval framework rather than each module inventing its own. Sharing a framework has a practical consequence: an approver holds a single queue containing every kind of request waiting on them, instead of hunting through separate screens for each. It also means a rule you understand in one place behaves the same everywhere — the same conditional routing, the same delegation, the same escalation. If you are comparing the category more broadly, our HR automation guide covers that ground; this page is about how the mechanism behaves inside Pitch N Hire.
How do multi-level approval chains work?
A chain is a sequence of steps, and each step names who has to act. A step can be a role relative to the requester, such as reporting manager, second-level manager or department head, or a specific person or group such as finance or HR operations. Steps run in order by default: the first level approves, the next is notified, and the request applies only when the last step clears. Where two people must both agree, a step holds parallel approvers and waits for both; where either is enough, the first response decides and the other is withdrawn. Rejection at any step returns the request to the requester with the reason rather than passing it onward. Chains differ per request type, so a half-day leave and a promotion need not travel the same route.
How does conditional routing pick the right approver?
Conditions are evaluated against the request and the requester's record at the moment of submission. Leave beyond a length you set can add a department head step. A change to a bank account can route to payroll rather than the line manager. A transfer can route to both the outgoing and incoming department heads. A request from one location or legal entity can follow an entirely different chain from the same request elsewhere. Because conditions read the employee record as well as the request, routing stays correct when somebody moves department without anyone editing the rule. Conditions are ordered and the first match wins, which keeps behaviour predictable — you can read the rule set top to bottom and know where a request will go before it is submitted.
What happens when an approver is on leave?
Delegation is set for a date range, either by the approver before they go or by an administrator on their behalf, and it names who receives their approvals during that window. Delegated requests appear in the delegate's queue with the original approver's name shown, and any decision is recorded against both, so the trail explains who actually acted. Delegation can be limited to certain request types where you do not want everything handed over. When the range ends, approvals revert automatically rather than needing to be switched back by somebody who remembers. Where nobody has been nominated, escalation rules take over instead of requests waiting indefinitely, which is the usual reason approvals stall in organisations running this over email: the absent approver stays invisible until somebody chases.
How do escalations work when an approval is overdue?
Each step can carry a time limit, measured from when the request reached that approver. Once the limit passes, the request escalates — a reminder to the current approver, then a move up the reporting line, or a transfer to a named group such as HR operations, depending on how you configure it. The escalation is recorded on the request, so the trail shows the step was moved and why. This matters most where a request has a real deadline: leave for next week, a regularisation before payroll input closes, a document needed for a joining date. Reporting on escalations shows where the process is genuinely slow rather than where people complain loudest, and whether the cause is a particular approver, a particular step or a request type.
What tasks fire automatically when someone joins, transfers or exits?
Lifecycle events trigger task lists rather than depending on a checklist somebody keeps privately. A confirmed joining date creates the onboarding tasks — asset allocation, access requests, document collection, induction scheduling, buddy assignment — each with an owner and a due date set relative to the joining date. A transfer creates tasks for both departments. A confirmed exit creates clearance tasks across IT, finance, admin and the reporting manager, and their results gate the settlement and the relieving letter through offboarding. Tasks appear in each owner's queue alongside their approvals, and progress shows as a completed count against the list rather than as a status somebody reports verbally. Overdue tasks escalate on the same rules that govern approvals.
How do people find out an action is waiting for them?
Notifications go out when a request or task arrives, and again on the reminder schedule you configure. In-portal, everything waiting on a person sits in one queue they can clear in a single session, which is what makes approvals happen on the day rather than at the next login. Email carries enough detail to decide and links back for the action itself. Managers who spend their day away from a desk work the same queue on mobile. Requesters see the state of what they submitted — which step it sits at, who holds it, how long it has been there — so chasing becomes unnecessary rather than merely discouraged. Notification volume is configurable per event, because a rule set generating constant mail gets muted and then ignored.
How do you see where a request is stuck?
Every request carries its own trail: the steps configured, the step it currently sits at, who holds it, who has acted, what they said and when. That answers the individual question. The aggregate question — where the approval process actually loses time — is answered by reporting across requests, grouped by type, step, department or approver. Patterns surface quickly: one step that always escalates, one team where regularisations sit for days, one request type whose chain is longer than the decision warrants. Because the data comes from the same records the modules use, it reads alongside leave, attendance and headcount figures in HR analytics rather than existing as workflow statistics disconnected from everything else.
Common approval routes and the conditions that change them
| Request | Typical chain | Condition that changes it |
|---|---|---|
| Leave application | Reporting manager | A long duration adds a department head step |
| Attendance regularisation | Reporting manager | Raised after payroll cut-off, it routes to HR |
| Bank detail change | HR, then payroll | Always bypasses the line manager |
| Timesheet submission | Project owner, then reporting manager | Client-billable projects add a finance step |
| Transfer | Outgoing head, then incoming head | Cross-entity moves add HR operations |
| Resignation | Reporting manager, then HR | A notice shortfall adds a department head step |
| Letter request | The HR team owning that letter type | Salary certificates route to payroll |
More HRMS features
HR workflows — evaluating options
Recruiting terms explained
Related recruiting questions
ATS for your industry
Free tools for this
Start here
HR workflows — FAQs
Can different departments have different approval rules?
What happens if an approver leaves the company?
Can a request need two people to approve at the same level?
Do approvers have to log in to act?
Can we automate tasks that are not approvals?
How do we stop the workflow rules becoming unreadable?
Is there a record of who approved what?
Can employees see where their request has reached?
Does workflow apply to onboarding and exit as well as day-to-day requests?
The applicant tracking system for recruiters and hiring teams
Pitch N Hire is an applicant tracking system. Post roles, screen applicants, run structured interviews, and make offers from a single pipeline — free for 1 user.
Free for 1 user · No credit card · Talk to a real hiring expert
See HR workflows in Pitch N Hire HRMS
Book a walkthrough on your own policies and data, or start on the free single-user plan.
Prefer to talk? Book a demo Talk to sales View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
