Leave request statuses field definitions

What this is

A reference for every status a leave request can hold, what triggers the transition, who acts next, and what side-effects the status carries (balance deducted? notification fired? attendance updated?). Use this together with the process guides — My Leave: apply, edit, cancel and return early for the employee path, Manage your team's leave for the manager path.

If you only remember one thing: a status is a contract. Each one tells you whose move it is, what is locked in, and what gets undone if things change.

Who acts next: the current approver

Every request that needs a decision creates an approval card on Pending Approvals. The card is keyed to one current approver — normally the employee's direct manager (or that manager's stand-in). If that approver has not decided after two fully elapsed working days on their own schedule (weekends, off-days and public holidays do not count), the card escalates automatically to the next manager up the chain and the clock restarts. When there is no higher manager the card is marked exhausted and a one-time note ("Escalation exhausted — no higher manager available") is posted on the approval's channel. There is no chain-wide race and no "first click wins".

The status values

PENDING

The starting state for any new leave request the employee submits, and the state an edit-cancelled-and-resubmitted request returns to.

Triggered by — employee submits from My Leave. Also reached when an employee edits a request that was still PENDING — the original is cancelled and a new PENDING one takes its place.
What is locked in — nothing. Balance is not deducted yet. Attendance is not marked.
Whose move next — the current approver on the approval card (see above). If they do not decide within two working days it escalates up the chain.
Visible to — the current approver, HR Admin, HR Reader and Site Admin. The employee sees it under My requests on Pending Approvals and in My Leave.
Auto-approve case — if no chain manager is configured at all, the system auto-approves at submit time and the request skips PENDING entirely. In practice this only fires for top-of-org employees during initial setup.
Acknowledge-mode case — some leave types (for example sick leave) are recorded immediately and the manager only acknowledges the notice; those cards show Acknowledge instead of Approve / Reject.

APPROVED

The terminal state for a healthy approved leave request — until and unless someone edits or cancels it.

Triggered by — the approver clicks Approve.
What is locked in — balance is deducted (carry-over bucket first, then current cycle). Attendance is marked. Both happen inside the same transaction as the status flip, so a partial-state cannot be seen.
Side-effects — APPROVED notification fires to the employee with the manager's optional comment.
Whose move next — typically nobody. Either the leave runs and the row stays APPROVED forever, or the employee edits / cancels it.

REJECTED

Terminal. Cannot be reverted; the employee has to file a new request if they still need leave.

Triggered by — the approver clicks Reject (a comment is required).
What is locked in — nothing balance-wise. The reason is stored as the manager comment.
Side-effect on splits — if this was the paid row of a paid + unpaid split, the linked unpaid row is auto-rejected with the comment "Auto-rejected: linked annual leave request was rejected".

CANCELLED

Terminal. The request never took effect, or it took effect and was undone with manager approval.

Triggered by — three possible paths:
- Employee cancels a PENDING request — immediate, no manager approval needed (it was never approved, balance was never deducted).
- The approver approves a CANCEL_PENDING (employee asked to undo an APPROVED leave) — balance is refunded, attendance is reversed.
- The approver approves an EDIT_PENDING — the original goes to CANCELLED as part of the edit-and-replace flow.
What is locked in — refunds and reversals are settled by the time the status flips.

CANCEL_PENDING

The waiting state when an employee has asked to cancel a leave that was already APPROVED.

Triggered by — employee clicks Cancel on an APPROVED row in My Leave.
What is locked in — the original leave is still in effect. Balance is still deducted, attendance is still marked. Nothing gets refunded until a manager approves the cancellation.
Whose move next — the current approver, on a separate Leave Cancellation card (separate work order from the original approval).
Why it exists — it forces an audit trail. An employee cannot quietly retract an approved leave to dodge a manager's decision; the cancellation has to be approved on its own merits.

CANCEL_REJECTED

Terminal-ish — the cancellation request was refused, so the leave reverts to APPROVED and runs as planned.

Triggered by — the approver clicks Reject cancellation on the CANCEL_PENDING card (a reason is required).
What changes — request status flips from CANCEL_PENDING back to APPROVED. The leave still happens. The employee gets a notification with the manager's reason.
Note — most teams treat this as a one-shot: the employee can re-submit a fresh cancellation, but a repeated reject is a signal that the leave has to be taken.

EDIT_PENDING

The waiting state on the original leave request while the manager reviews the edited version.

Triggered by — employee edits an APPROVED request via My Leave → Edit. The system creates a new request with the new dates / duration linked to the original via parentRequest, and flips the original to EDIT_PENDING.
What is locked in — the original leave is still in effect. Balance is still deducted for the original dates. The original cannot be edited again (no edit-on-edit). The new linked request is the one that goes to the approver as a Leave Edit card.
Whose move next — the current approver, on the new linked row.

EDIT_REJECTED

Terminal. The manager declined the edit; the original stays as it was.

Triggered by — the approver rejects the linked edit request.
What changes — original flips back from EDIT_PENDING to APPROVED. The edit row keeps the EDIT_REJECTED status as a historical record so the employee can see what was tried.

COUNTER_PROPOSED (custom-schedule / OT only)

A manager has counter-proposed different hours on a custom-schedule request and is asking the employee to accept or reject the new times.

Triggered by — the manager opens the request with Review on the manager-only Pending Approvals tab of the My Leave page and clicks Counter-Propose, which opens the Propose Alternative Times dialog (new start and end times plus a required reason). The Custom Schedule card on the unified Pending Approvals page then shows "Counter-proposal sent" with the proposed times.
Whose move next — the employee, from the Manager Counter-Proposed Times — Action Required panel on My Schedule › Custom Schedules, which shows the date, the manager's proposed times and message, with Accept and Reject buttons.

COUNTER_ACCEPTED (custom-schedule / OT only)

Terminal. The employee accepted the manager's counter-proposed hours; the custom schedule is approved with the new times.

Triggered by — employee clicks Accept on a COUNTER_PROPOSED row.

How states relate to the leave work order

Every leave request has a backing work order (WO). Approval, edits, and cancellations each create their own WO step or their own WO entirely, so an audit-friendly timeline exists for any request:

Approval WO — created on submit. Holds the LEAVE_APPROVAL line for the manager decision and the LEAVE_COMPLETE line for the auto-step that deducts balance + marks attendance.
Edit WO — created when the employee edits an APPROVED leave. Holds the LEAVE_EDIT line; on approval it refunds the original and applies the edited dates inside one transaction.
Cancellation WO — created when the employee cancels an APPROVED leave. Holds the LEAVE_CANCELLATION line; on approval it refunds balance and reverses attendance.
Stand-in selection step — only fires when the submitter is themselves a manager. Picks a tempManager for their department covering the leave start date.

The View WO link in My Leave History opens the relevant WO so HR or the employee can see the whole timeline (who submitted, who acted, when).

Side-effects at a glance

Use this as a quick lookup for what is true at each status. Balance and Attendance refer to the leave's days/dates being applied to the employee's record.

PENDING — Balance: not deducted. Attendance: not marked. Notifications: SUBMITTED.
APPROVED — Balance: deducted. Attendance: marked. Notifications: APPROVED.
REJECTED — Balance: not deducted. Attendance: not marked. Notifications: REJECTED.
CANCELLED (from PENDING) — Balance: not deducted. Attendance: not marked. Notifications: none unless this was a CANCEL_PENDING flow.
CANCELLED (from CANCEL_PENDING approval) — Balance: refunded from APPROVED. Attendance: reversed. Notifications: CANCEL_APPROVED.
CANCEL_PENDING — Balance: still deducted. Attendance: still marked. Notifications: CANCEL_REQUESTED.
CANCEL_REJECTED — Balance: still deducted (back to APPROVED). Attendance: still marked. Notifications: CANCEL_REJECTED.
EDIT_PENDING — Balance: original still deducted. Attendance: original still marked. Notifications: EDIT_SUBMITTED on the original conversation.
EDIT_REJECTED — Original goes back to APPROVED. Edit stays as historical record. Notifications: EDIT_REJECTED.

Tips for reading badges in the wild

A paid + unpaid split shows up as two PENDING rows with the same start/end and same employee. They are linked but have separate IDs and approve independently — though if you reject the paid one, the unpaid one is auto-rejected.
A request in EDIT_PENDING always has a sibling row with status PENDING (the edit) on the approver's queue. Looking only at the original and not seeing it in the queue does not mean nothing is happening.
CANCEL_PENDING does not mean the leave is cancelled. It means a cancellation has been requested. The leave is still in effect until a manager approves the cancellation.
A request can move from APPROVED → EDIT_PENDING → APPROVED (different dates) or back to APPROVED (same dates, edit rejected). Either way the row is still there with its original ID.
A card that has escalated shows the escalation on the approval's channel ("Escalated — no decision after 2 working days"). The request status itself does not change when it escalates; only the approver does.
HR exports treat APPROVED and CANCEL_PENDING the same way for balance + attendance reporting — both mean the days are out. Cancellation is only reflected on approval.