How leave approvals work

Ask AI

The default chain, custom workflows, replacements, edits, cancellations, request history and who can see attachments

What happens between Submit and approved or rejected.

Where decisions happen

The request's review page, Review leave request, is at https://app.squadbear.com/approvals/<request id>. Inbox carries the badge and lists every request waiting on you; Home repeats those rows under Your day. Time off → All requests lists the leave records you may see and opens a pending row on the review page. The review page and Time off → All requests both require the manager or admin role. An approver on the employee role sees the request in Inbox but cannot open the review page; they decide through a connected agent (approve_leave_request / reject_leave_request, scope approval:write).

The default chain

Approval is set on each leave type: an approval workflow, Granted at once, manager notified, or Granted at once, nobody told. The chain is materialized at submission, one step per matching workflow step. Every preset routes its vacation and unpaid types through the built-in Simple manager approval workflow - one step, the direct manager - and grants sick leave at once with the manager notified. A step whose only approver is the requester is recorded as approved by them, not skipped; an approver away on approved leave that day is replaced by their manager or the first active admin.

Before you submit, the form says who the request goes to: Goes to: its first step's approvers, Goes to any admin: when no manager is set, or Granted at once, manager notified / Granted at once, nobody told. Once submitted, the request on Time off → My leave and its Team calendar row say who it is Waiting on.

Custom workflows

Admins define chains on the Approval workflows tab of Settings → Leave: 1-5 steps, each with 1-8 approvers - direct manager, manager's manager, team lead, a named employee, or any admin - and the first to respond decides the step. Each step takes an optional duration condition and an SLA in hours. A leave type picks its workflow in the Approval field of its request rules (Settings → Leave → Leave types → [type]); a new rule applies to requests made from its date. A workflow that a leave type uses cannot be switched off. An optional Same-day cut-off routes a request for today made after a set time through a different approval.

Replacements

When a leave type has Replacement required on - no preset turns it on - a request cannot be submitted without naming a colleague to cover, who cannot be the requester. A cover who is away or already covering someone else is a warning, never a refusal, also when the cover is assigned or changed later. Only they can accept or decline.

Editing and cancelling

Only the requester or an admin can edit a request, and only while it is pending - editing re-validates against the creation rules and restarts the chain from step one. Cancelling is open to the requester, their manager, or an admin, on pending or approved requests; the days return to the balance, and a partly-taken approved request can be cancelled from a date forward, keeping days already taken. A rejected or already-cancelled request cannot be cancelled again - the call is refused with a 409.

Closed time periods

Once an admin closes time through a date (Settings → Time tracking → Close time), approved leave on or before that date is locked for everyone, admins included, because payroll may already have used it. Approving a request with a day in the closed period, cancelling approved days in it, and booking leave there that would be approved at once (sick leave, say) are all refused with a 409 period_closed. A request can still be booked there as pending, with a warning that it cannot be approved until the period is reopened. To change leave in a closed period, an admin reopens it (with a reason), makes the change, and closes it again. Closing time needs the Team or Enterprise plan, but reopening never does: a workspace that moves to the Free plan can still move the date earlier or clear it. If the Time tracking module is turned off, turn it back on to reopen.

Request history

The request detail carries a Request history trail - up to 100 entries, oldest first: submission, edits with the fields that changed, step decisions, escalations, cancellations and cover events. The requester, anyone on an approval step, the requester's manager and admins see it.

Attachments

Attachments are added by the requester when submitting, or from the request's detail on My leave. The requester, admins, and any candidate on any step read them, whatever the request's status; get_request applies the same rule. Only the requester or an admin writes or deletes one; after the request leaves pending, deleting is admin-only.

Worked example

Tomasz requests 8 days of Vacation. Submitting counts the 8 days as pending on his Vacation allowance and materializes one step from Simple manager approval; his manager's approval turns them into used days. Had Marta added a second step for requests over 5 days, any active admin, to that workflow, it would wait on her too.