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 — Apply for leave 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.

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 via Apply for Leave (HrLeaveService.submitRequest). 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 — any manager in the employee's chain. First click wins.
• Visible to — direct manager, every chain manager above them, the assigned stand-in (if the direct manager is on leave on the start date), HR Admin, HR Reader, Site Admin.
• 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.

APPROVED

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

• Triggered by — chain manager 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; chain announcement fires to other chain managers so they know the row is gone from their queue.
• 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 — chain manager clicks Reject (a reason 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).
  • Chain manager approves a CANCEL_PENDING (employee asked to undo an APPROVED leave) — balance is refunded, attendance is reversed.
  • Chain manager 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 History.
• 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 — chain manager (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 — chain manager rejects the CANCEL_PENDING (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 History → 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 manager's queue.
• Whose move next — chain manager, on the new linked row.

EDIT_REJECTED

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

• Triggered by — chain manager 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 an OT request and is asking the employee to accept or reject the new times.

• Triggered by — manager clicks Counter-Propose on an OT row (My Leave → Apply for Custom Schedule, manager view).
• Whose move next — the employee, from the Manager Counter-Proposed Times panel on Apply for Custom Schedule.

COUNTER_ACCEPTED (custom-schedule / OT only)

Terminal. The employee accepted the manager's counter-proposed hours; the OT 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) somewhere in the manager'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.
• 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.