Availability, published roster and change request are three separate objects: how to set a cutoff, version the roster, order swaps, and handle a late change.
Key takeaways
- Availability is not a request for a shift. It is a declaration of a time window by the employee, an input to planning rather than a commitment by the organisation.
- A roster is a version, not a table that gets edited. Publishing freezes a version, and every change produces a new version with a defined diff against the previous one.
- A submission cutoff is what lets a roster converge. Without one, every new declaration forces a replan and the roster is never finished.
- A swap needs three approvals in a fixed order: the covering colleague, a qualification check, then the manager. Manager-first approval collapses when the colleague declines.
- After lock, a change is not a swap but an incident: a cover list, a named caller, and a marker on the roster that the shift was worked by somebody else.
The confusion comes from squeezing three different objects into one table: the availability an employee declared, the roster that was published, and the change request filed afterwards. Each has a different owner, a different cutoff and a different lifecycle. This describes data modelling and process, not employment policy.
Three objects, not one table
| What it is | Who creates it | When it can change | What it proves |
|---|---|---|---|
availability | the employee | until the cutoff | when the employee declared they were free |
roster_version | the planner | only by creating a new version | who was assigned in the published version |
change_request | employee or manager | until the decision | who asked, who approved, and when |
shift_actual | attendance capture | after the shift | who actually worked |
That separation settles the most common argument in an operational business: "I said I couldn't." The employee is right that a declaration was made, the manager is right that a roster was published, and the two are talking about different objects. Held as separate records, you compare the declaration timestamp against the publication timestamp and close the question in ten seconds.
The last row matters especially: shift_actual is not what was planned. If payroll reads from the roster instead of from attendance capture, every unrecorded swap becomes a payslip error. The interface between the two is described in the attendance-to-payroll interface file.
Is a declaration of availability a request for a shift?
No, and that distinction removes a large share of the friction. Availability is an input: it says when somebody can be assigned, not when they will be. Someone who declared six windows may receive two, and that is a normal planning outcome rather than being ignored.
For the distinction to hold, the declaration itself needs structure:
- A time window with a start and an end, not "mornings" and not "can't do Tuesdays".
- A type:
available,preferredorunavailable. Three values, not free text. - Validity bounded to that period's cutoff, so last week's declaration does not silently affect next week.
- A submission timestamp, which is the evidence in any later disagreement.
- A way to express a repeating weekly declaration, since most availability does not change week to week. The iCalendar standard defines
RRULEfor that, and alsoRECURRENCE-IDto identify one modified instance inside a recurring set - exactly the structure needed to say "every Monday morning, except the 19th".
Cutoff, publication and version
A roster converges only when there is a line after which the input stops moving. A full weekly cycle, for a week starting Sunday 2026-10-11:
- The availability submission window opens on Monday 2026-09-28.
- The cutoff is Tuesday 2026-10-06 at 18:00. A declaration arriving later is stored but does not enter the current plan.
- The planner builds a draft. The draft is not visible to employees, because a roster that can be seen but is not final is a source of error.
- Version v1 is published on Thursday 2026-10-08 at 12:00. Publication freezes the version and sends one message per employee containing only their own shifts.
- Any change after publication produces a new version. The v2 notification is a diff: the two rows that changed, not the whole roster again.
- Lock at 12 hours before each shift start. From there a change does not travel the normal route.
Step five is what prevents the most common failure: resending the entire roster on every update. Somebody holding three messages with three full tables does not know which is current, and will usually act on the first. A short diff carrying a version number solves it. Comparable principles for structured replies to an outbound message appear in the RSVP response workflow over SMS and WhatsApp.
The order of swap approvals, and why it is not the reverse
A swap between two employees is one request with three gates, and the order between them decides how much work is wasted:
- The colleague receives the request and accepts or declines. A decline closes the request without anyone else touching it.
- An automatic eligibility check: does the covering person hold the qualification the shift requires, and does the swap collide with another shift of theirs in the same version?
- The manager approves or declines, seeing both earlier results on one screen.
The reverse order, where the manager approves first, produces approvals that later collapse and forces them to approve the same request twice. The automatic check in the middle is what removes most of the traffic: a collision is shown to the employee at submission instead of surfacing on the manager's screen the next day.
The request states are requested, peer_accepted, manager_approved, rejected, withdrawn and expired. expired is needed because a request nobody touched before lock has to close itself, otherwise it stays open and creates the illusion that somebody will still deal with it.
What changes when a swap arrives twelve hours before the shift?
Everything, because there is no longer time for an approval route. After lock a change is not a request but an operational incident, and it needs its own process:
- A cover list defined in advance per role, ordered by who is called first rather than at random.
- One named person who makes the calls, with a phone number on the shift card. A group message is not a process.
- A record of every attempt: who was called, when, and what they said. Without it there is no way to know whether everyone was actually reached.
- When no cover is found, the shift is marked
uncoveredrather than deleted. A shift that vanished from the roster is lost information. - After the shift,
shift_actualcarries whoever worked it, so the monthly review does not rely on the plan. Comparing plan against capture is covered in reviewing time clock data before payroll.
Sources
Frequently asked questions
How far ahead should a roster be published?
The number depends on the business, but what really matters is the gap between publication and the availability cutoff. Less than two days between them leaves no planning time, and too large a gap makes the declarations stale. Three to five days between cutoff and publication works in most operational businesses.
What do you do with somebody who declares availability after the cutoff?
Store the declaration with its timestamp and flag it as late, without pulling it into the current version. A build-up of late declarations is a management figure worth measuring per person, because it is the most common reason a roster fails to converge on schedule.
Does every swap need manager approval?
Not necessarily, but the answer should be a rule rather than a judgement call each time. You can define that a swap between two people holding the same qualification and with no collision is approved automatically, while anything outside those conditions goes to the manager. The rule itself is stored as configuration so it can be inspected.
How do you stop two people believing they are on the same shift?
By making an assignment belong to exactly one roster version and putting the version id in every message. Two contradictory messages always come from two versions, and with the version number visible you can say immediately which one is superseded. Without it the argument is between two screenshots.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.