TEASEDocs
ProductsClubHow-to

Approve or deny an off-schedule shift request

Review a team member's request to work outside their planned roster before they're let in — the switch a workspace controls per role, not per person.

Why a request exists at all

Whether clocking in outside the planned roster needs your sign-off is a per-workspace setting (Off-schedule shift requests: not allowed / self / with manager approval — see Team access). Under the manager setting, a team member pressing "start shift" outside their schedule doesn't open one — it files a TeamShiftRequest and waits.

Reviewing requests

GET /shift/requests?status=pending lists what's waiting. What a given viewer sees depends on their own grant:

  • a member with the "Manage the roster and shifts" capability sees every pending request in the workspace;
  • anyone else with shift access sees only their own — even a manager without that specific capability is scoped to themselves, because approving other people's shift requests is a separate power from having a manager rank.

Deciding

POST /shift/requests/{request_id} takes {decision: "approve" | "deny"}.

  • Approve opens a real OperatorShift row immediately, for exactly the number of minutes the member asked for — it closes itself on schedule rather than staying open until someone remembers to end it. Extending it further means the member files a new request.
  • Deny just marks the request closed; nothing opens.

A request can only be decided once — a second call against an already-decided request answers 409, not a silent overwrite of the first decision.

A self-approved request looks the same afterward

If the workspace setting is self rather than manager, the member's own request is approved automatically the instant they file it, and a real shift opens without anyone reviewing it — the request row still exists for the audit trail, but this page's review flow never triggers.

What's next

On this page