Shift lifecycle — from draft to approved#
For: Manager | Admin You’ll need: Nothing.
A shift moves through several statuses on its way from „first sketched on the calendar“ to „approved by a manager“. This article walks each status, what triggers a transition, and what gets locked along the way. Payroll runs over approved time entries — payment itself isn’t a status the schedule tracks.
Shift statuses#
A shift sits in one of three statuses, shown as a badge on every shift block and list row.
Draft — newly created. Visible to planners and managers; not visible to shift workers. Free to edit, move, resize, and delete.
Published — released to the team. Workers see it on their schedule and in notifications. Still editable for managers, but edits and deletes are constrained by downstream state (see „Locks“, below).
Cancelled — the shift won’t run. Stays on the calendar as a record so reports can account for it.
Promotion happens one way: drafts get published in bulk from the publish horizon. There is no „unpublish“ — to take a shift back, cancel it.
Assignment statuses cascade from the shift#
Each assignment (one person × one shift) inherits the shift’s status:
Draft assignment — pencilled in. Worker doesn’t see it.
Published assignment — on the worker’s schedule. Used by coverage and validation.
Publishing a shift flips every one of its draft assignments to published, unless an assignment is already locked (see below).
Time entry statuses live on the assignment#
Once a published shift starts, its assignment becomes the home for clock-in / clock-out times. The lifecycle:
Published — no clock data yet.
Submitted — the assignment has a clock-in and clock-out (or the worker / manager has filled them in). Submitting triggers leave and time-compensation accruals where applicable.
Approved — a manager has signed off. Approval also locks the underlying shift.
Two reverse arrows undo each step. Unsubmit clears clock data and reverses leave / time-comp accruals; unapprove clears the audit stamp and lets the entry be edited again. See Timesheet.
Leave request lifecycle#
Leave requests have their own state machine, tied to the calendar via an auto-created event block.
Pending — created by the worker (or a manager on their behalf). Awaiting review.
Confirmed — approved. Deducts hours from the leave balance and spawns the calendar event.
Declined — refused at review. Calendar event removed if it was auto-created.
Revoked — was confirmed, then cancelled. Reverses the leave-balance transaction and removes the calendar event.
Pending and declined requests can be deleted; confirmed and revoked stay for audit. See Leave requests.
Company periods lock everything downstream#
A company period goes from open to started to closed.
Closing a period locks every time entry whose date falls inside it. After close, shifts, assignments, and time entries in the locked range can’t be edited, deleted, or unsubmitted — Shiftavo shows a „locked“ banner and refuses the change. See Why a shift can’t be edited or deleted: locked periods.
An admin reopens a period by editing it back to open, which releases the lock.
Recurring shift series#
A recurring shift is a parent rule plus generated child shifts. Editing or deleting a child opens a scope chooser:
This — affects only this occurrence; the parent rule remains.
Following — splits the series at this date.
All — regenerates the whole series from the new parent rule (preserves per-occurrence exceptions).
See How to edit a recurring shift and How to delete a recurring shift.
When something looks locked#
If a save or delete is refused, the cause is almost always one of these — in this order:
The underlying time entry has been approved → unapprove first.
The shift is in a closed company period → reopen the period (admin only).
The shift is cancelled and you’re trying to clock it.