How the System Works
How a swap actually resolves
What the system does between one worker sending a swap and both calendars changing.
A swap is an offer between two named workers, and nothing moves until the second one answers.
How it resolves
Eligibility is checked at creation and again at acceptance, because it can lapse in between. A failed check refuses the request. It binds whoever receives a span, so Harnwell training and float rules follow the hours.
A block held in one pending request cannot enter another, so the same hours are never promised twice. Acceptance onto a seat that already changed hands fails, protecting its new holder.
| Kind | Answer by |
|---|---|
| Shift swap | 3 hours before the earlier span starts |
| Float swap | 24 hours after the later span ends |
| One-sided handoff | 24 hours after the span ends |
| Permanent swap | 7 days after it was sent |
Cancellation, a vacated seat, and expiry each end a request without moving hours. The other party is told as it happens.
Why it works this way
Float swaps and handoffs are usually recorded after the shift is worked. Their windows run past it, so acceptance rewrites the calendar retroactively.
A handoff skips the weekly cap, because it re-attributes hours somebody was already scheduled to work.
A permanent swap trades recurring slots for the rest of the period. It skips weeks the initiator no longer owns; the confirmation lists them.
What this means for you
You can cancel your own request. You cannot un-accept one.