# 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 {doc}`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 {doc}`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: 1. **Published** — no worked hours confirmed yet. 2. **Confirmed** — the hours have been recorded and signed off as correct (clocked in/out, or filled from the schedule). Confirming triggers leave and {doc}`time-compensation ` accruals where applicable. Depending on your company's mode, the employee confirms their own hours first or a manager does — see {doc}`/track-time/timesheet/how-confirmation-works`. 3. **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 {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`. ## 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 — {{ app_name }} shows a **'locked'** banner (with who approved it and when) and refuses the change. See {doc}`locked-period-rejections`. 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 {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: 1. The underlying time entry has been **approved** → unapprove first. 2. 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}`recurring/index`