HR workflows and approvals in Pitch N Hire HRMS

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.