Sora İK · Workflow & Approval Designer
How do you design HR approval workflows? An approval hierarchy for leave and documents
Last updated: · Yiğit Yalman
In short
An HR approval workflow is the set of rules deciding whose approval a request, such as leave or a document, needs and in what order. A well-designed workflow rarely goes beyond two or three steps, ties approvers to roles rather than people, and defines in advance where a request goes when the approver is away.
How do you design an HR approval workflow?
Workflow design starts by identifying the type of request and its risk; then you write down the number of steps, the approver at each step and the condition that triggers the flow. What happens when the approver is on leave or has left is part of the design, not an exception added later.
- List the request types. Annual leave, unpaid leave, excused leave, document or expense requests may each need their own rules.
- Assess the risk. A short leave can pass with one approval; a long or unpaid leave affects the budget and team planning, so it needs a second step.
- Tie approvers to roles. Write “direct manager” or “HR” instead of a person's name, so the flow survives a change of personnel.
- Set the conditions. Define which flow applies to which request type and to requests longer than how many days.
- Write the absence rule. If the approver is on leave, a delegate decides; if no approver can be found, the next manager up or HR decides.
- Measure and adjust. Track the number of pending approvals and how long they wait; redesign any step that keeps getting stuck.
What do steps, roles and conditions mean in an approval workflow?
An approval workflow has three building blocks. A step is an ordered approval point the request passes through; a role names who decides at that step by job rather than by person; and a condition determines which requests trigger the flow.
| Request | Condition | Steps |
|---|---|---|
| Short annual leave | Below the number of days you choose | Direct manager |
| Long annual leave | For example, longer than 10 days | 1. Direct manager 2. Department head |
| Unpaid leave | Any length | 1. Direct manager 2. HR |
| Excused leave backed by a document | Marriage, birth, bereavement | HR (document check) |
| Expense request | Above an amount you set | 1. Direct manager 2. Finance |
Where do approvals break down with email and Excel?
When approvals run on email, the rule is not written down; it lives in people's memory. When the approver goes on leave, requests wait, who gives the second approval is debated every time, and months later nobody can find out who made a decision, or when.
- The request sinks beneath other messages in the approver's inbox; the employee learns its status only by asking.
- Delegation while the approver is on leave is not written down; either the request waits or someone without authority approves it.
- An “I approve” reply is copied into the leave spreadsheet by hand; any gap between the sheet and the thread shows up in the puantaj (monthly attendance ledger) and payroll.
- After a reorganisation, requests still go to the old manager.
- Nobody can measure how long each request waits, so the bottleneck stays invisible.
How do you set up approval workflows in Sora İK?
In Sora İK, approval workflows are built with a form on the settings screen, without code, and today they apply to leave requests. Each workflow holds up to five steps in sequence; at each step the approver is the employee's manager, that manager's own manager, a role or a named user.
- Conditions: a workflow is chosen by leave type and a minimum number of days; a workflow with no condition matches every leave request. A company can define up to 50 workflows, and each request is attached to the first active one that matches.
- Skipping: in a person-based step, the step is skipped if there is no approver, if the approver is the requester, or if that person already approved the previous step; role steps are never skipped.
- Delegation: an approver hands their authority in person-based steps to another user for a date range of up to 366 days.
- HR decision: HR can decide on any request; if HR is not the next approver, its decision is final.
- Open requests are protected: the workflow is copied onto the request when it is opened, so later changes do not affect requests already in progress.
- Notifications and record: when a person-based step comes up, the approver gets an email; the request details show who closed each step, when and with what decision.
On the roadmap: parallel steps, per-step waiting times with automatic escalation to a higher approver when time runs out, a workflow preview, conditions by department, and workflows for requests other than leave (expenses, advances, documents). A visual drag-and-drop design canvas is also on the roadmap; today, steps are ordered in the form. An overview of the product is on the Sora İK page; details: Workflow & Approval Designer — full feature list.
What should IT and management watch for in approval workflows?
An approval workflow is an internal control tool: it separates the person who makes a request from the person who approves it and makes every decision traceable. The workflow itself needs protecting too: who can define flows, how changes are logged and how accurate the org chart is decide how far approvals can be trusted.
- Segregation of duties: nobody should approve their own request; in Sora İK, a person step is skipped when the approver is the requester.
- Audit trail: in Sora İK, approval decisions, workflow changes and delegations are kept in the audit log, which the company owner and system administrator roles can read out of the box.
- Who can define flows: limit this to a few people; in Sora İK, the permission is assigned by default to the HR, system administrator and company owner roles.
- Dependence on the org chart: manager steps follow the reporting lines set in the org chart; a wrong line sends the request to the wrong person.
- Person-based steps: when an approver chosen by name leaves, you must update those steps by hand; use role steps where you can.
How to set up manager links is explained in the org chart guide, and role design for approval permissions in the HR software security guide.
Modules that work with approval workflows
An approval workflow does not run on its own: the request comes from the leave module, the approver is found in the org chart and permissions are read from role definitions. The guides below explain each of these links.
- Annual leave tracking guide: Tracking annual leave through entitlement, balance and approval steps.
- Employee self-service guide: Employee and manager self-service, a rollout plan and visibility rules.
- Organisation chart guide: Setting up departments and positions, keeping the reporting line current and how the chart drives approvals.
- HR software security guide: A vendor-neutral IT checklist for role-based access, two-step verification and audit logs.
Frequently asked questions
How many steps should an HR approval process have?
For most HR requests, one or two steps are enough; each extra step adds waiting time without reducing risk by the same amount. Reserve a second step for requests that affect the budget, team planning or a legal check. Flows of more than three steps are often a sign of distrust nobody has put into words, so clarify the rule first.
What happens to a leave request when the approver is on leave?
In a well-designed workflow, this is decided in advance: the approver names a delegate before going on leave, or the request goes to a higher manager or HR. In Sora İK, the approver sets a delegate for a date range; delegation applies to person steps in requests attached to a workflow, while in role steps the other users holding that role decide.
Can approval workflows be changed without coding?
In current HR software, flows are usually changed from a settings screen; when evaluating, ask how a change affects open requests. In Sora İK, workflows are edited with drop-down lists and buttons in a form, with no scripting. Because the workflow is copied onto the request when it is opened, changes apply only to new requests; open ones finish under the old flow.
Who approves a request when no workflow is defined?
Even without workflows you need a default rule, or requests are left with no owner. In Sora İK, if no workflow matches, the decision falls by default to the employee's next-level manager; higher links in the management chain and the HR role can also conclude the request. This lets you define workflows first for risky leave types only and widen them over time.
Which HR processes can use approval workflows?
In general, a workflow suits any process where the decision depends on more than one person: leave, expenses, advances, documents, hiring approval or pay changes. In Sora İK, workflows today are defined for leave requests only, with leave type and a minimum number of days as conditions. Workflows for expense, advance and document requests are on the roadmap.
