# From shift draft to payroll **For:** Manager | Admin **You'll need:** Nothing. A shift travels through six stages between *pencilled in* and *paid*. The same record carries the data the whole way — there is no hand-off, no separate "payroll system" to sync with. This article walks each transition: what triggers it, what flips, and what locks behind you. ## The flow at a glance ``` Draft │ publish ▼ Published │ clock-in / clock-out ▼ Submitted │ manager approve ▼ Approved │ period close ▼ Locked │ ▼ Payroll export ``` Each arrow is a deliberate action by a specific role. Each transition narrows what's still editable. ## 1. Draft — the planner's sandbox A new shift is **Draft**. Visible to planners and managers; **invisible to shift workers**. Free to move, resize, reassign, or delete. This is where most of your work happens. Bring shifts in from a {doc}`schedule template `, a {doc}`recurring pattern `, or {doc}`Alt+drag `. Validate against your team in the {doc}`coverage grid ` and the {doc}`assignment dropdown `. Iterate until you're happy. A draft shift has draft assignments. Workers see nothing yet. ## 2. Published — released to the team You promote drafts in bulk from the {doc}`publish horizon `: pick a cutoff date and {{ app_name }} flips every draft shift starting on or before that date to **Published**. Each shift's draft assignments flip with it. What changes: - Workers see the shifts on their calendar and (per their notification settings) get an email. - The shifts feed availability and coverage as committed work. - Managers can still edit, but edits are now visible to assignees. There is no "unpublish". To pull a shift back, cancel it — the worker sees the cancellation but the shift stays on the calendar as a record. See the full state diagram in {doc}`/plan-schedules/shifts/lifecycle`. ## 3. Submitted — the clock data is in Once a published shift starts, workers (or a manager on their behalf) clock in and out. When both ends are recorded, the assignment is **Submitted**. Submission is what makes the time real. Specifically, it: - Locks in the worked hours that drive overtime tiers and premiums. - Triggers leave accrual for accrual-style policies. - Triggers {doc}`time-comp accrual ` for time-comp policies. A submitted entry is still editable. **Unsubmit** clears the clock data and reverses the accruals. See {doc}`/track-time/timesheet/index`. ## 4. Approved — the manager signs off A manager reviews submitted entries on the {doc}`timesheet ` and approves them. **Approved** is the sign-off state — what you'd filter the payroll export to when you want to see only manager-blessed hours. Approval also **locks the underlying shift** — you can't change times, position, or assignment after approval without first unapproving. **Unapprove** clears the audit stamp and re-opens the entry. ## 5. Period close — bulk lock for payroll A {doc}`company period ` (typically a pay cycle) is either **open** or **closed**. Closing the period locks every time entry inside it: no more edits, no more deletes, no more unsubmits. Until an admin re-opens the period, the data is frozen. Closing is the contract with payroll: *the numbers won't move under you*. ## 6. Payroll export With the period closed, the {doc}`payroll summary ` is the final view. It groups time entries by person inside a pay cycle (the cycle length is configurable per tenant on the company period) and totals regular hours, overtime tiers, premiums, paid and unpaid absence, time-comp, and gross pay. By default the report includes Published, Submitted, and Approved entries — filter to **Approved-only** for a clean post-close export. Export the report to CSV, XLSX, or PDF and hand it to your payroll vendor. Payment itself doesn't have a status — once you've exported, the payroll vendor takes over. ## What locks behind you, in order | State | What you can still change | | --- | --- | | Draft | Everything | | Published | Everything; edits notify workers | | Submitted | Times, breaks, assignment; submit can be undone | | Approved | Nothing, until **unapproved** | | Closed period | Nothing, until an admin **re-opens** the period | When a save is refused, unapprove the entry. Reopen the period if needed. See {doc}`/plan-schedules/shifts/locked-period-rejections`. ## The other people in the flow - **Shift worker** — sees the shift only after publish. Can submit their own clock data or have it submitted on their behalf. - **Manager** — publishes, approves, exports. - **Admin / Owner** — opens and closes company periods; reopens a closed period if a correction is needed after the fact. ## Related - {doc}`how-the-data-fits-together` - {doc}`three-ways-to-build-a-schedule` - {doc}`/plan-schedules/shifts/lifecycle` - {doc}`/plan-schedules/publish-horizon/index` - {doc}`/track-time/timesheet/index` - {doc}`/set-up-your-company/company-periods/index` - {doc}`/reports-and-payroll/payroll-summary`