Manage your team's leave

What this guide covers

Everything a manager does for the people in their management chain: approving, rejecting, editing-on-behalf, creating leave for an employee, handling a cancellation request, and the chain-manager + stand-in rules that decide whose decision counts.

The matching employee guide is Apply for leave. For status-badge meanings see Leave request statuses field definitions.

The chain-manager rule (the one rule that explains everything)

Every leave, custom-schedule (OT) and OT-cancellation request is visible to every manager above the employee in the org chart — direct manager, that manager's manager, and so on up to the root. Any one of them can decide. The first click wins. Once a chain manager approves or rejects, the request disappears from everyone else's queue and a notification goes to the chain saying who acted.

This is intentional. It means:

A direct manager who is on leave or unreachable does not block their team.
A senior manager can step in for an urgent decision without asking for handover.
You can defer informally — the Direct manager column on every row tells you who the employee normally reports to, and you can leave the row alone if it is not yours to decide.

Stand-in managers

When you apply for leave, the form requires you to pick a Stand-in Manager from your scope (the people you manage or peers you trust). The system writes that person into your department's tempManager slot for the start date of your leave. While you are off, any leave or OT request from your team that would normally route to you routes to the stand-in instead.

Stand-in is set per department, per date — it covers the day your leave begins. If your team submits a request days after you go on leave, the stand-in still picks it up because the chain walks via the temp-manager flag.

When you come back, the temp-manager flag clears and your normal routing resumes.

The Pending Approvals page

Open My Stuff → Pending Approvals. This is your inbox for everything anyone in your chain has asked you to decide on:

Pending Approvals — counts and leave queue

Three count cards across the top tell you what is waiting in each queue: Leave, Custom Schedule / OT, and OT Cancellations. The Refresh button (top right) re-pulls the queues without losing your place. If everything is clear you see a green check and "Nothing pending. You're all caught up."

Watch for split rows. When an employee asks for more days than they have available, the system splits the request into a paid row + an Unpaid row (linked, same start/end dates, same employee). They show up as two adjacent lines in your queue. You can decide on each independently — see "Override the unpaid split with a negative balance" below.

Approving or rejecting a leave request

Find the row, click Approve or Reject.

Approving

Approve leave dialog

The Approve dialog shows the employee's name and a Manager comment field (optional). Click the green Approve to confirm.

What happens:

Status flips to APPROVED.
The employee's balance is deducted for that leave type — first from the carry-over bucket, then from the current cycle balance. Balances can go negative if you are explicitly allowing that (see split-handling below).
Attendance is marked accordingly so daily-attendance scans no longer flag the employee as absent on those days.
A chat notification fires to the employee. A second notification announces to the rest of the chain that the decision is final.

If a second chain manager tries to act after you have decided, they see a "Heads up — already actioned" warning and the queue refreshes.

Rejecting

Reject leave dialog — reason required

Reject opens a similar dialog but the reason is required — the employee needs actionable feedback so they know whether to refile, change dates, or escalate.

What happens:

Status flips to REJECTED. No balance is deducted.
The employee gets the rejection notification with your reason.
If the request was a paid + unpaid split, the linked unpaid row is auto-rejected with the comment "Auto-rejected: linked annual leave request was rejected" — it does not make sense to keep half of a split alive.

Approving an EDIT_PENDING request

When an employee edits an already-approved leave request, you receive a separate approval — a new row appears in your queue tied to the same employee. The original stays visible but is locked (you cannot edit-on-edit) and shows status EDIT_PENDING.

Approve the edit → the original days are refunded to the employee's balance, the original goes to CANCELLED, the new request goes to APPROVED, and attendance is recalculated for the new dates.
Reject the edit → the edited request goes to EDIT_REJECTED and the original stays approved exactly as it was.

This is why you should treat an edit as "approve a new request" rather than "approve a small change" — the approve action does the full bookkeeping for both rows.

Approving a cancellation (CANCEL_PENDING)

When an employee asks to cancel a leave that you previously approved, the cancellation needs your approval too — even if it is well before the start date. The flow exists so an employee cannot quietly retract a leave they were approved for and dodge the audit trail.

The original APPROVED row stays visible in their history but flips to CANCEL_PENDING. A new row lands in your queue with the cancellation reason.

Approve the cancellation — the original goes to CANCELLED, the balance is refunded, attendance is reversed.
Reject the cancellation — the original stays APPROVED, the leave still happens. The employee gets a notification with your reason.

Approving custom schedule (OT) and OT cancellations

Custom-schedule rows show Date, Start, End, Minutes and Reason. Approve adds an optional comment; reject requires a reason.

For OT cancellations the action buttons are labelled Approve cancel / Reject cancel — reject cancel means "the OT must still happen", so make sure that is actually what you mean. The reason on a reject is required precisely because rejecting a cancellation is a decision the employee needs to push back against if it is not feasible.

You can also counter-propose different OT hours from the My Leave → Apply for Custom Schedule tab on the employee's row — useful when the employee has the right idea but the wrong start time.

Override the unpaid split with a negative balance

When a request comes in as a paid + unpaid split (because the employee asked for more days than they had), you have three options:

Approve both rows as-is — the employee gets paid days for what they had, and unpaid days for the rest. Standard outcome.
Reject both — the employee has to refile with a shorter request or a different type. Auto-rejection of the linked row keeps things clean.
Override the unpaid row to a negative balance — instead of treating the shortfall as unpaid, debit it against the same leave type. The next monthly accrual will pay it back. This is the right call when you trust the employee and the shortfall is small. Use this carefully — it lets the balance go negative on the books.

The "convert unpaid to negative" path is on the unpaid row's dialog (look for Allow negative balance or similar). Once you submit, the unpaid row vanishes from pending, the primary row is approved, and the leave-type's balance shows a negative figure until the next accrual catches up.

Create leave on an employee's behalf

Sometimes an employee cannot file (off sick, no system access, on the road). Open My Stuff → My Leave → Create Leave for Employee (manager and HR only).

Create Leave for Employee tab

Pick the employee, then fill in the leave type, dates and duration. The form mirrors Apply for Leave but the request is auto-approved as you submit — no second approval is needed because you, the manager, are submitting it.

When the request would exceed the employee's balance, you choose at submit time:

Mark as unpaid — the same paid + unpaid split gets created and both rows are auto-approved.
Allow negative balance — the primary leave type takes a negative balance.

A note from you (a managerLeaveNote field on the dialog) is recorded against the request so HR can see why it was created on-behalf.

Reading the inbox: what to look at on each row

For a leave row, glance at:

Type — does this match what you would expect for this employee? Sick + Monday + no certificate is worth a quick chat.
Days — sanity check the number against your team's headcount and current workload.
Reason — the employee's own reason, useful colour for borderline cases.
Direct manager — if it is not you, you are approving as a chain manager. Consider whether to defer to the direct manager unless there is a reason to step in.

For an OT row:

Minutes — total minutes requested. Combined with Date, this tells you whether someone is heading into a 70-hour week.
Reason — was this asked for, or is the employee unilaterally proposing it?

For an OT cancel row:

Date — the originally approved OT date. If it is the day-of, ask whether the work was actually done before approving the cancel.

Notifications fired (so you know what your team will see)

The notification service fires a chat message and an email at every state change:

SUBMITTED — employee submitted; chain managers + the requested manager + the temp-manager (if assigned) are notified.
SPLIT_SUBMITTED — the system created a paid + unpaid split.
APPROVED / REJECTED — your decision, with your comment if you wrote one.
CANCEL_REQUESTED / CANCEL_APPROVED / CANCEL_REJECTED — for the cancellation flow.
EDIT_SUBMITTED / EDIT_APPROVED / EDIT_REJECTED — for the edit flow.
MANAGER_CREATED / MANAGER_AUTO_APPROVED / MANAGER_BALANCE_OVERRIDE — when a manager files on behalf, auto-approves on file, or converts unpaid to a negative balance.

If your employee mentions they did not get a notification, check that they have a chat / email subscription against attendance events.

Tips and gotchas

Refresh if the queue feels stale — a colleague may have decided a row already. The button re-pulls without losing your place.
A reason is mandatory on every reject (leave, OT, OT-cancel) so the employee always has something to act on.
First decision wins is enforced server-side. Two managers clicking Approve at the same instant is fine — only one decision is recorded; the other gets the "Heads up — already actioned" warning and a refreshed queue.
A manager-created and auto-approved request still routes through the same notification fan-out, so HR sees it in their reports without any extra plumbing.
HR Admins, HR Readers and Site Admins see everyone's pending items, not just their chain — useful for HR sweep-up at month end.