build.allanninal.dev

Part 5 of 7 · Shift scheduler series ~5 min read

How a shift swap gets approved

A schedule lands in Marco’s Slack DM on Friday morning. He’s got Sunday 4–10pm, and something just came up. There’s a “Request swap” button. What happens when he taps it? The honest answer is “it depends on what he’s actually asking for.” This post walks through the three things a swap request can be — cover, drop, time-off — and how the published rota, the hours, and the audit trail all stay in sync while the manager keeps the final say.

Key takeaways

  • Three actions per request: cover (find a replacement, route to manager), drop (back to the open pool), time-off (hold for next draft).
  • Cover reuses the Part 3 rules — only cleared, available, under-cap people are offered.
  • Every swap routes to the manager for a quick yes or no. Nothing is auto-confirmed.
  • An approved swap updates the published rota and the running hours so fairness stays intact.
  • The Request-swap button is a Slack interactive message backed by a Function URL.

Three actions on a swap request

Three actions on a swap request A diagram showing one input on the left flowing through a small interactive Slack panel, then branching into three action paths. Far left: a "Shift in Slack DM" box showing a published shift — day, time, role — with three Slack-button placeholders below: Cover, Drop, Time-off. The staffer taps one button. The middle column shows the three branches. Branch one, Cover: the scheduler reuses the Part 3 rules to find cleared, available, under-cap people who could take the shift, ranks them by who is furthest below their hours target, and routes the best one as a proposed swap to the manager with a yes or no; on the manager's yes, a Function URL Lambda updates the published rota in the ss-shifts table, adjusts both people's running hours, and writes a swapped event to the audit trail. Branch two, Drop: the staffer gives the shift back to the open pool rather than naming a replacement; the shift is marked open in ss-shifts and surfaced to the manager, who can offer it to the team or fold it into the next draft; nothing is reassigned without the manager. Branch three, Time-off: the request is really a day-off ask, not a single-shift swap; it is recorded against the week so the next draft treats the person as unavailable, and the affected shift is flagged for the manager. The right side shows the convergence: every action writes a row to the ss-audit DynamoDB table with timestamp, shift id, action, by-user, and notes. A note at the bottom: every swap needs a manager yes — the scheduler proposes the replacement, it never reassigns a shift on its own. Shift in Slack DM day, time, role [Cover] [Drop] [Time-off] Action 1 Cover • Find cleared, free, under-cap people • Route best to manager • On yes, rota updated Action 2 Drop • Shift back to open pool (no named replacement) • Manager offers it or folds it into next draft Action 3 Time-off • Mark day unavailable for the next draft • Affected shift flagged — manager decides Audit trail DynamoDB ss-audit timestamp · shift_id action · by-user notes Every swap needs a manager yes — the scheduler proposes the replacement, never reassigns on its own.
Fig 5. Three actions per swap request, three different effects. Cover finds a replacement and routes it to the manager. Drop returns the shift to the open pool. Time-off holds the day for the next draft. Every action needs a manager yes and writes to the audit trail.

Action 1: cover (the most common)

Marco can’t do Sunday but wants it covered so the floor isn’t short. He taps Cover. The Function URL Lambda reuses the exact rules from Part 3: it lists everyone cleared for the shift’s role and skills, free that day, and under their max-hours cap and rest gap. It ranks them by who’s furthest below their weekly hours target — the same fairness logic the draft uses — and picks the best one.

That proposed swap goes to the manager as a Slack message: “Marco wants Sunday 4–10pm covered. Best fit is Aisha (cleared, free, at 14h of 20h). Approve?” with a yes or no. On yes, three things happen, in order. First, the published rota in ss-shifts is updated: the shift moves from Marco to Aisha. Second, both people’s running hours in ss-hours are adjusted — Marco down, Aisha up — so fairness stays honest. Third, a action: swapped row is written to ss-audit with both names, the shift, and the timestamp. Aisha and Marco each get a short confirmation DM. On no, Marco is told the swap wasn’t approved and the shift stays his.

The manager is never handed a blank “someone wants to swap, sort it out” message. They get a specific, already-fair proposal and a single decision to make.

Action 2: drop (back to the pool)

Sometimes a staffer can’t cover the shift themselves and doesn’t know who can — they just need it off their plate. Drop is for that. The shift is marked open in ss-shifts rather than reassigned to anyone, and it’s surfaced to the manager as an open shift that needs a home.

From there the manager has choices: offer it to the team (the scheduler can post it to a shared channel as “open shift — Sunday 4–10pm, who can take it?” and the first qualified taker routes back for a yes), or simply fold it into the next draft so the drafter places it fresh. Either way, nothing is reassigned without the manager. Drop is the honest version of “I can’t, can someone else?” — it leaves a clear open shift instead of a vague group-chat plea.

Action 3: time-off (the day-off ask)

Sometimes the request isn’t really about one shift — the person needs the whole day, or a stretch of days, off. Time-off handles that. It records the unavailability against the week so the next draft treats the person as off, exactly like an approved Lane 2 note from Part 2. The affected shift on the current published rota is flagged for the manager, who decides whether to cover it now (via the same cover flow) or let the next draft sort it.

Time-off doesn’t silently rewrite the published week. It marks the intent and surfaces the gap, so the manager can choose between covering it immediately and waiting for the redraw. If the day was already published as a shift, that shift stays Marco’s until the manager either approves a cover or re-drafts — the system never leaves a shift quietly uncovered.

Every action is logged, every action is reversible

The ss-audit table records every cover, drop, and time-off with the person who asked, the manager who decided, the timestamp, and a snapshot of the rota before and after. If a swap gets approved by mistake (wrong person, wrong shift), the manager can run an “undo last swap” through a small admin command that reads the previous-state snapshot and restores both the rota and the hours. The undo is itself an audit row, so the trail of changes stays clean.

This kind of reversibility matters because swaps happen fast and under pressure — the Friday-night “can anyone cover” is exactly when mistakes creep in. The audit trail is the memory the manager can lean on when someone asks, three weeks later, why they ended up with that Sunday.

Next post: the cost breakdown. The whole system above runs in coffee-money territory at small-team volume; Part 6 explains exactly where the dollars go and why it stays cheap.

All posts