Workflow & Approval Designer: Decide who approves leave requests, and in what order

Who is it for, and what problem does it solve?

The workflow designer is for businesses that run approval rules from people's memory or email threads and leave requests waiting when a manager goes on leave. When the rule is not written down, who approves has to be asked every time, no one knows whether a long leave went through a second approval, and the answer to “Who approved this?” cannot be found later.

• HR manager: defines leave approval rules once and manages changes from a single screen.
• Team manager: sees incoming requests in the approval queue and names a delegate before going on leave.
• Employee: sees which step their request is at and whose approval it is waiting for.

Plan scope and user limits are explained on the pricing page.

What does the workflow and approval designer do?

The designer lets you define, as rules, the approval steps, approvers and conditions for requests in the Leave Management module.

• Workflow: consists of a name, conditions and 1–5 sequential steps. Workflows are arranged in priority order; a request is attached to the first active workflow whose conditions match. Up to 50 workflows can be defined per company.
• Step types: the employee's direct manager, the manager's manager, a role (company owner, system administrator, HR or a company-specific role) or a specific person. Managers are found from the manager link in the org chart.
• Conditions: leave types and a minimum number of days. If the condition is left empty, the workflow matches all leave types and any duration.
• Step skipping: happens only in person steps (direct manager, manager's manager, specific person): if no approver is found, if the approver is the employee themselves, or if it is the same person as the approver of an earlier person step, the step is skipped. Role steps are never skipped.
• Delegation: a user hands over, for a specific date range, their approval authority in workflow steps that resolve to them to another user; a delegation lasts at most 366 days. Delegation applies only to requests attached to a workflow; for a request without a workflow, no authority passes to the delegate, and higher-level managers in the chain and HR decide. Users with permission to define workflows can also set up delegation on someone else's behalf.
• HR decision: HR can always decide; if HR is not the approver of the next step, its decision is final and the remaining steps are marked.
• Copy to the request: the workflow is copied into the request when the request is created. Changing or deleting the workflow later does not affect open requests.
• Notifications: if the next step resolves to a person, a notification goes to that person's work email; no email is sent for role steps, and the request appears in the approval queue of the users in that role. The approval or rejection outcome is emailed to the employee.
• Decision record: who completed each step, when and with what decision is shown in the request details; decisions made by delegation and by HR decision are marked separately.

Parallel steps, per-step waiting times and automatic escalation, a preview showing in advance who a workflow will go to, and workflows for request types other than leave are not available yet; they are coming soon.

How does it work?

An approval workflow is set up in five steps and can be used immediately.

1. Open a new workflow. On the “Approval workflows” screen under settings, give the workflow a name and mark it as active.
2. Choose the conditions. Decide which leave types the workflow applies to and the minimum number of days for requests it covers.
3. Add steps. Choose a type for each step; for a role or person step, select the role or user. Change the order of steps with the up and down buttons.
4. Order the workflows. If more than one workflow can match the same request, move the more specific one up; the request uses the first active workflow that matches.
5. Track requests. See which step a request is waiting at in the “Approval steps” section of the request details; update the workflow if needed.

What does “without software development” mean, and what are its limits?

Workflows are built on a form with drop-down lists, checkboxes and buttons; no scripts or code are written. Steps are ordered on the form today; a visual (drag-and-drop) design area is coming soon. You do not need to open a ticket with a software team to change a workflow. By default, permission to define workflows belongs to the company owner, system administrator and HR roles. A custom role used in a workflow step cannot be deleted until it is removed from the workflow.

In return, the designer currently works only for leave requests. Steps that send requests to external systems, free formulas, creating new data fields and conditions by department or employee group are not available yet; these are coming soon as well. Features for connecting to external systems, such as the open API and webhooks, are listed as upcoming modules on the Platform & Integrations category page, and free-form employee requests on the Employee Management category page. Approval decisions and workflow changes are kept in the audit log; information on how these records are protected is on the security page.