Shift swap requests

Staff-initiated trades: a cook asks a colleague to cover their Saturday, the colleague accepts, the manager approves, and the schedule actually moves — all without phone calls or whiteboard scribbling.

What it does

Without this feature, swaps happened off-system: text the colleague, agree informally, ping the manager to update the rota, hope they remember. The trail was invisible, and the rota would drift from reality.

This feature makes the trade auditable end-to-end. Three people are involved:

The requester — the staff member who can’t make their shift.
The target — the colleague being asked to cover.
The manager — the gatekeeper who approves the final move.

Both staff sides can act from their phones via the My shifts page. The manager handles approvals from the Roster planning page.

A swap moves through up to three states before landing:

Awaiting target’s response — the requester just sent the request.
Awaiting manager approval — the target accepted, the manager hasn’t decided yet.
Approved (and executed) — the schedule has been updated. From this moment, the target is on the roster instead of the requester.

Either party can cancel before the manager approves. The target can reject. The manager can deny. Any of those endings closes the request without changing the schedule.

How to use it

As the requester (staff)

Open My shifts in the sidebar.
Find the future shift you can’t make. Tap ↔ Swap on the right side of the card.
Pick a colleague from the dropdown — only active staff at the same venue, you can’t pick yourself.
Optionally add a note (e.g. “doctor’s appointment”, “wedding to attend”). The colleague and the manager both see it.
Tap Send request. Done — the colleague will see it next time they open the app.

You’ll see your request appear in a Your swap requests in flight panel at the top of My shifts. It shows whether the colleague has responded yet or whether it’s now with the manager. You can tap Cancel any time before final approval to pull the request back.

As the target (staff)

When someone asks you to cover, opening My shifts shows an amber Swap requests awaiting your response panel at the top:

The requester’s name.
The day, date, and time of the shift you’d be covering.
Their note, if any.
Accept and Reject buttons.

If you tap Accept, the request moves to the manager. The shift isn’t yet yours — the manager has to give the final OK. If you tap Reject, the request closes and the shift stays with the requester.

As the manager

When a target accepts, the next time you open /admin/roster you’ll see a blue banner above the tabs: ”↔ N shift swap(s) awaiting your approval”. Tap it.

A modal lists each pending swap: requester → target, the shift’s date and time, the original note. Two buttons per row:

Approve & swap — confirms the trade. The schedule is updated immediately: the requester is taken off this date, the target is put on. The shift card on the Week tab reflects the change instantly.
Deny — closes the request as rejected. The schedule stays as it was. (Useful if you spot a problem the staff didn’t see — coverage conflict, or staff who don’t have the right department mix.)

What happens behind the scenes

The system stores three pieces of information at request time:

The requester’s source shift. This can be either a one-off shift the manager created or a recurring shift expanded from a weekly pattern. Both are referenced.
A snapshot of the shift’s time, departments, and venue. Frozen at request time. If the manager edits the underlying recurring pattern between request and approval, the swap still refers to the same agreed-upon block — no surprises.
Notes from each step. Requester’s note, target’s response note, manager’s decision note. All visible in the audit chain.

When the manager approves, the system performs one of two equivalent moves:

For a one-off shift — patches the shift’s assigned employee to the target. The card on the Week grid changes hands.
For a recurring-pattern shift — writes a single-occurrence cancellation for the requester on that date AND creates a fresh one-off shift for the target with the same time and departments. The recurring pattern itself is untouched (the requester is still on the pattern for every other occurrence).

This is one atomic database transaction. There’s no half-done state where the requester is removed but the target hasn’t been added.

The reactivity layer pushes the change to every connected client immediately. The requester’s My Shifts page drops the card. The target’s My Shifts page picks it up. The manager’s roster grid updates. No refresh needed.

Examples

🤝 Routine cover Sara realises she has a wedding on Saturday at 19:00. Friday morning she opens My shifts, taps ↔ Swap on Saturday, picks Marco, types “wedding — sorry for short notice”. Sends. Marco sees the amber panel that afternoon, taps Accept (he wanted extra hours anyway). The manager reviews on Friday evening at home, approves. By the time Saturday comes the rota shows Marco in the Sala column. Three taps each.

⚠️ Target pre-empts the manager Marco accepts Sara’s swap, but next morning realises he forgot he has a doctor’s appointment Saturday morning that probably won’t end on time. He opens My Shifts → Your requests in flight isn’t there (he’s not the requester). What he can do: ask Sara to cancel from her side, OR ask the manager to deny. Or better, the manager hasn’t approved yet — Marco taps the rejection on his end… wait, the request is now in pending_manager state, the target’s actions are over. He has to ask Sara to cancel or the manager to deny. (UI improvement candidate: let the target pull back their accept while waiting for manager.)

⚠️ Recurring-pattern swap Marco is on the recurring “Mon-Fri 18-23 Kitchen”. He needs Tuesday off this week only. He opens My shifts, taps ↔ Swap on Tuesday, picks Luca, sends. Luca accepts. Manager approves. On the Week grid, this Tuesday’s Kitchen card now shows Luca, with a “swap” note in the system. Every other Tuesday in future weeks still shows Marco — the recurring pattern wasn’t touched.

⚠️ Schedule conflict the manager catches Luca accepts a Saturday cover for Sara, but the manager notices Luca is already scheduled for Bar at the same time. Manager taps Deny. The request closes, both staff see the rejection on their next visit. The manager messages Luca to suggest a different swap target.

My shifts — where staff initiate and respond to swaps.
Weekly schedule — the planning grid that ultimately shows the swapped result.
Comparing plan with reality — once the swap is approved and the day passes, the actual time-clock punches reconcile against the new planned shift, not the original.