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. Leave →
Approvals lists the leave records you may see and opens a pending row on the review
page. The review page and Leave → Approvals 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_request / reject_request, scope
approval:write).
The default chain
The chain is materialized at submission, one step per matching workflow step. The seeded Vacation policy uses two: the direct manager decides first, and above 2,400 scheduled minutes - 5 days on the default 8-hour day - a second step adds every active admin. Sick leave approves automatically; Unpaid leave binds to the built-in Simple manager approval workflow. 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.
Custom workflows
Admins define chains at Workspace settings → Approval workflows: 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 workflow binds to a policy at Workspace settings → Leave policies → [policy] through the Approval workflow field.
Replacements
When a policy requires a replacement - the seeded Vacation and Unpaid leave policies do - a request cannot be submitted without naming a colleague to cover, who cannot be the requester. Assigning or changing one later is rejected when that person is already absent or covering. 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.
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 and names a cover. Submitting reserves 3,840 minutes and materializes two steps - 8 days clears the 2,400-minute threshold. His manager clears step one; step two waits on any active admin - Marta's approval converts the reservation into used days.