# 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 {doc}`publish horizon </plan-schedules/publish-horizon/publish-up-to-a-cutoff>`. 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:

1. **Published** — no clock data yet.
2. **Submitted** — the assignment has a clock-in and clock-out (or the worker / manager has filled them in). Submitting triggers leave and {doc}`time-compensation </rules-and-compliance/time-compensation/auto-accrual>` accruals where applicable.
3. **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 {doc}`/track-time/timesheet/index`.

## 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 {doc}`/manage-leave/leave-requests/index`.

## Company periods lock everything downstream

A {doc}`company period </set-up-your-company/company-periods/index>` 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 — {{ app_name }} shows a "locked" banner and refuses the change. See {doc}`locked-period-rejections`.
- 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 {doc}`recurring/edit-a-recurring-shift` and {doc}`recurring/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:

1. The underlying time entry has been **approved** → unapprove first.
2. The shift is in a **closed company period** → reopen the period (admin only).
3. The shift is **cancelled** and you're trying to clock it.

## Related

- {doc}`/plan-schedules/publish-horizon/index`
- {doc}`/plan-schedules/assignments/index`
- {doc}`/track-time/timesheet/index`
- {doc}`/manage-leave/leave-requests/index`
- {doc}`/set-up-your-company/company-periods/index`
- {doc}`recurring/index`