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.
Drafts get published in bulk from the publish horizon. Unpublish retracts a published shift back to draft while it’s still just shared — once a worker has clocked in, the shift has started, or its hours are approved, unpublish is blocked and you cancel the shift instead.
General events publish the same way. A company meeting, a training day, or a party is a draft until you publish it, and only then does it appear on the team’s schedule. Draft it, get the details right, publish when it’s confirmed — and the RSVP box (‘Going’ / ‘Maybe’) appears for the people on it.
What an assignment carries#
An assignment (one person × one shift) has no draft/published status of its own — its visibility simply follows the shift. What it does carry is two independent answers:
Acceptance — if your company turns on shift acceptance, this is the worker’s reply to a published shift: ‘Pending’, ‘Accepted’, or ‘Declined’. A declined assignment drops out of coverage counts. It’s optional, and off by default.
Worked hours — the timesheet status once the shift is over: ‘Published’ → ‘Confirmed’ → ‘Approved’ (covered next).
Publishing a shift doesn’t flip a separate assignment status — it just makes the shift, and everyone on it, visible to the team. A locked assignment (one whose hours are approved) keeps the whole shift from being unpublished or edited.
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 worked hours confirmed yet.
Confirmed — the hours have been recorded and signed off as correct (clocked in/out, or filled from the schedule). Confirming triggers leave and time-compensation accruals where applicable. Depending on your company’s mode, the employee confirms their own hours first or a manager does — see How confirmation and approval work.
Approved — a manager has signed off. Approval also locks the underlying shift.
Two reverse arrows undo each step. Undo confirmation 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.
Approval locks the shift#
Approval is the only lock. When a manager approves a time entry, the underlying shift, its assignment, and the entry itself can’t be edited, deleted, or have its confirmation undone — Shiftavo shows a ‘locked’ banner (with who approved it and when) and refuses the change. See Why a shift can’t be edited or deleted.
To release the lock, unapprove the time entry. There’s no period to close or reopen.
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:
The underlying time entry has been approved → unapprove first.
The shift is cancelled and you’re trying to clock it.