Time-off requests
Leave requests arrive continuously and schedules are built periodically. Most of the pain in handling them comes from that mismatch, and from the fact that a request made the day before generation and a request made the day after publication are completely different problems being handled by the same email thread.
Request periods
A request period is a window — you set the dates — during which staff submit preferences and leave requests for a future schedule period. It opens, staff submit, it closes, and the generator runs against what it collected.
The value is that it makes the deadline a property of the system rather than of one person's patience. Nobody has to decide whether a request that arrived late counts. Everyone can see the window and what they submitted into it.
Requests inside the window are constraints on a schedule that does not exist yet, which is the cheapest possible time to handle them. The generator simply builds around the approved ones.
Approval against coverage, not guesswork
An approver sees what granting the request would do: how many people are already off on those dates, whether the resulting coverage is still legal, and which shifts would need covering.
That is the question an approver is actually trying to answer, and without it they are reconstructing it from a spreadsheet and memory. Two requests for the same week, each individually reasonable, are the common failure — and they are only visibly a problem when something shows them together.
After publication
A request granted after the schedule is published leaves shifts uncovered. The product does not pretend otherwise: those shifts become open shifts and are offered to everyone eligible.
This is the honest handling of a genuinely hard situation. The alternative — quietly reassigning somebody — is how a schedule stops being trusted.
Request types
The product distinguishes four, because they need different handling:
- Time off — a request not to be scheduled.
- Preference — a request to be scheduled a particular way, satisfied where possible and reported where not.
- Swap — a trade with a specific colleague. See shift swapping.
- Open shift pickup — a claim on a shift nobody is assigned to.
Treating a preference as a soft constraint rather than a leave request is what lets the generator use it: "I would rather not do Mondays" is useful information the generator can act on, and useless information if the only options are approve and deny.
Common questions
Can staff request time off after the schedule is published?
Yes, and the product treats it differently from a request made before generation. A pre-generation request is a constraint the generator works around; a post-publication one creates shifts that need covering, which the open-shift mechanism then offers to everyone eligible.
What is a request period?
A window during which staff may submit preferences and leave requests for a future schedule period. It opens, it closes, and the generator runs on what it collected — which replaces the usual scramble of requests arriving by email until the day the schedule is built.
Related
- Schedule publishing — why draft and published are different states.
- Nurse scheduling — self-scheduling windows.