Approving leave
Leave → Approvals is your inbox. It has two tabs: Pending and History.
What lands in your inbox
Section titled “What lands in your inbox”You see a request because the approval workflow resolved you as the current step’s approver — usually because you’re the employee’s designated leave approver or their reporting manager.
The scope adjusts itself to your permissions, with no switch to set:
- Most approvers see only what is currently assigned to them.
- Holders of blanket approval rights see the whole organization’s backlog, with their own actionable rows floated to the top and tagged Yours.
Oldest submissions come first, so the queue drains in the order people applied.
If an approver is themselves on leave on the day, the request may have been re-routed to their manager or to HR, depending on your organization’s out-of-office policy. That shows up in the request history as Auto-routed to {Name}.
Reading a row
Section titled “Reading a row”Each row shows the requester’s name, the leave type, the dates and day count, and when it was submitted with a relative age — Submitted 9 Jun 2026 · 4 days ago. The reason, if given, appears in quotes underneath.
Badges to watch for:
| Badge | Meaning |
|---|---|
| Yours | You can act on this one (shown only in the org-wide view). |
| Cancellation | This is a request to cancel an already-approved leave, not a new booking. |
| Date mismatch / Day count mismatch / Document unreadable | The AI document check flagged the attachment. Advisory only. |
Selecting the requester’s name opens a profile peek; selecting anywhere else on the row opens the full request.
Approve or reject from the inbox
Section titled “Approve or reject from the inbox”Approve acts immediately with no confirmation — a toast says Approved and the row disappears.
Reject opens a dialog with a recap of the request and a Reason (optional) box, placeholder Share why — the requester will see this. A reason is genuinely optional; you can reject with the box empty. The requester gets a notification carrying whatever you wrote.
Return for edit instead of rejecting
Section titled “Return for edit instead of rejecting”If the request is nearly right — wrong dates, missing detail — send it back rather than rejecting it. Return for edit is only on the request detail page, so open the request first.
-
Open the request from the inbox.
-
Select Return for edit.
-
Write a Reason — this one is required. Placeholder: Explain what needs changing — the requester will see this.
-
Confirm with Return for edit.
The request becomes Returned, the requester gets your reason, and the employee’s balance hold is kept so the days stay reserved while they fix it. When they resubmit, it comes straight back to your step — earlier approvals in the chain aren’t repeated.
Cancellation requests can’t be returned for edit. Approve or reject those.
Deciding on the request page
Section titled “Deciding on the request page”Opening a request gives you more to work with than the inbox row.
An amber banner reminds you where you are: You’re viewing {Name}’s leave request. Any action you take here is recorded against your name in the audit trail.
Summary carries the requester, the current approver, the workflow name, the covering colleague, the reason, and the attached document with a View link plus any AI scan verdict.
Others on leave during this period is the section worth checking before you approve. It lists everyone else with approved leave overlapping these dates, their leave type, and whether it’s a half-day. If nobody else is away it says No one else has approved leave during {date}.
History is a full timeline — who submitted, which steps opened, every approval, rejection, comment, delegation, auto-routing, coverage change, return and resubmission, each with a timestamp and any comment in a quote bubble.
Delegating a step
Section titled “Delegating a step”If a decision isn’t yours to make, you can hand the step to someone else. That person becomes the assignee for this request only — it doesn’t change the workflow or anyone’s future routing.
Multi-step and quorum approvals
Section titled “Multi-step and quorum approvals”Workflows can require more than one approval:
- Sequential steps run in order. Each step must complete before the next opens, and the request is approved when the last one does.
- Quorum steps need a set number of approvals from a pool of people — any one of them, a specific number, or all of them in order.
Your inbox only shows requests whose current step is yours. A request waiting on step 2 won’t appear for a step-3 approver until step 2 clears.
History tab
Section titled “History tab”History lists decided requests, newest first, capped at 50 by default. Scope follows the same rule as the inbox: most approvers see requests they personally decided, blanket approvers see everything in the organization.
Rows are read-only, showing the status pill — Approved, Rejected, Cancelled, Withdrawn — and when it was decided. Select one to reopen the full request and its timeline.
Things you can’t do as an approver
Section titled “Things you can’t do as an approver”- Approve your own request. The guard applies even to blanket approvers.
- See balances. Balance visibility needs the leave-admin permission.
- Edit the request. Return it for edit and let the employee change it, or ask HR to shorten an approved leave.
- Withdraw on the employee’s behalf. Only the requester can withdraw.
If a leave type is disabled mid-flight
Section titled “If a leave type is disabled mid-flight”Occasionally HR disables a leave type while a request is still open. Approving then fails with {Type} is disabled. Reject or withdraw this request, or re-enable the leave type first. Rejecting still works.