Roster & scheduling

Three things, in order. A shift catalogue — your shifts, named once. A roster — one site, one period, a grid of people against days. And publication — the moment that grid stops being a plan somebody is drafting and becomes the plan of record, which the people it names are told about and which attendance and payroll then answer to.

Everything else here — swaps, availability, open shifts, patterns, coverage, auto-fill — hangs off those three.

Uncovered means unchanged. An employee or a date that no published roster covers behaves exactly as it did before this module existed: same absence logic, same flat expectations, same pay. Turning rostering on changes nothing anywhere until a roster is published, and a site that never publishes one never notices the module is there.

The shift catalogue is where your shifts get their names. Do this once, before the first roster.

Retire a shift you no longer run rather than deleting it — retiring takes it out of the planner and leaves every roster that used it readable. Deleting is only offered while nothing has used it.

New roster asks for a site, a start date and a length — 7, 14 or 28 days — and opens the grid. Rows are the people deployed at that site who could work the period (active and on-leave both, because people come back mid-period); columns are the days.

A cell holds one of three things: a shift, a rest day, or nothing at all. One shift per person per day — a split service day is two shift types or a note, not two cells. Underneath the cells the grid shows what you would otherwise have to remember: approved leave, public holidays, and anything the person has said about their own availability.

An open shift is a cell with a shift but no name — a slot you know you need filled and have not filled yet. It is a question, not an answer: it never counts as cover, and it publishes as a gap, deliberately visible.

Validate runs the rule engine over the grid as it stands — saved or not — and the same engine runs again inside publish. What the planner saw is what the gate enforces; there is no second, stricter check waiting at the end.

Hard rules block publishing. They are the ones a plan must never break:

• Two entries for one person on one day.
• Less than the minimum rest between consecutive shifts — 11 hours unless the site sets its own. Night handovers are measured across the midnight boundary properly, not by date.
• More consecutive worked days than the ceiling — 6 unless the site sets its own. Streaks and rest are read across the period edges, so the count does not reset just because the paperwork does.
• Somebody on approved leave, or outside their employment dates.
• A shift longer than the site's statutory daily ceiling (standard hours + the OT maximum), where the site has entered one.
• A cell with neither a person nor a shift, which says nothing.

Soft findings warn and never block. They are the planner's conscience:

• Rostering someone on a day they said they cannot or would rather not work.
• Fairness — one person carrying noticeably more nights, weekend days or public holidays than a colleague.
• Coverage under or over the target for that weekday and shift.
• A rest day standing alone between two worked days, and backward rotation — an earlier start following a later one.
• Open shifts still unassigned.

The split is deliberate and worth defending to whoever asks for it to be stricter. A wedding on a Tuesday out-plans the weekly coverage default; running thin on purpose is a decision, and the validator's job is to make it visible rather than to forbid it. Equally, an employee's stated preference never blocks the manager's call — it is a warning, so the disagreement is honest and on the record.

Publish stamps the roster with the time and the person, and notifies every member of staff it names — a bell notification and an email where they have a login.

A published roster is immutable. There is no edit. To change it, take a revision: the grid is copied into a fresh draft that supersedes the original, you change what you need to, and you publish again. The original stays exactly as staff saw it — it is the record of what people were told at the time, which is precisely what you want to be holding when somebody says "but I was told I was off".

Publishing a revision tells only the people whose own days changed. Fixing one steward's Thursday does not ping the whole resort. Where several published rosters cover the same site and date, the newest publication governs — that is the plan attendance, payroll, the portal and the API all read.

A draft can be deleted; a published roster never can. Two targeted amendments are allowed without a revision, because neither changes anybody's published plan: naming an open slot, which fills a hole, and an approved swap, which exchanges two cells in place.

In the staff portal, My portal ▸ Shifts shows this week and the next two, from published rosters only. Drafts do not exist there, and where a roster has been revised the portal shows the governing version — so what a person reads is exactly what they will be judged against. Add to calendar downloads their shifts as a calendar file for their phone; it is a download behind their login, not a subscription link.

Availability is where somebody states a day they cannot work, or would rather not — a specific date or a recurring weekday, up to twenty live statements each. It is an ask, not a block: the planner sees it under the grid, the validator raises it as a warning, and the roster stays the manager's decision.

A swap takes three steps, in this order: the employee asks a named colleague at their own site, the colleague accepts, and only then does it go to management through the ordinary approval engine. On approval the two cells are exchanged in place, both parties are told, and the change is audited. Nothing in the portal ever writes a roster cell on its own.

Shifts from tomorrow onward only, one in-flight swap per shift, and a rest day cannot be given away (ask for the swap the other way round). If the roster is revised while an ask is sitting there, the ask lapses rather than quietly applying to a plan that has moved.

Open shifts work the other way. Published open slots at a person's own site appear in their portal, and I'm interested puts their hand up. Roster managers get one notification per slot that carries the current count rather than a ping per volunteer, and assign from the planner with one click. Cover a gap by asking, not by assigning.

A pattern is a named rotation written as shift codes — M M E E N OFF OFF — kept alongside the shift catalogue. Applying one to a row stamps it across the period, cycling from the start. Days already planned are never overwritten, and a code that no longer resolves to a usable shift skips its day rather than guessing, so you see the gap and decide. Copy week forward is the same instinct with no setup: last week again, leaving anything already planned alone.

Coverage targets are how many heads you need per weekday and shift at a site. The planner shows have-against-need per day and the validator warns both ways — under and over. Remember that only a named head is cover; an open slot never counts toward a target.

Auto-fill names open slots and closes coverage gaps with the least-burdened person who can feasibly take each one — never breaking a hard rule, preferring whoever has said nothing against the day, then the lightest fairness load, then the fewest planned hours. It is a deterministic heuristic, not a solver: the same draft fills the same way twice, the full rule engine gets the last word and takes back anything it flags, and what lands is a draft you review like any other. It never publishes anything.

For a date a published roster covers, the day's expectations come from the shift rather than from the site default: expected hours, the late cutoff and its grace. Three consequences follow, and they are the point of the whole module:

• A no-show on a rostered day is Absent — even on a Friday, even on a public holiday. Somebody rostered to work a holiday who does not turn up has not had a holiday.
• A rostered rest day deducts nothing, whatever day of the week it falls on.
• A night shift counts as one night. Punches within three hours either side of a planned overnight span are attributed to that shift's date, so a 21:55 in and a 07:05 out is one Present night with the right hours instead of two broken half-days.

Optionally, per site, the weekend premium can follow the published plan instead of the calendar — the premium lands on the person's rostered rest day rather than on Friday. Public holidays stay premium either way, and sites left on the statutory basis behave byte-for-byte as before. Worked hours themselves never come from the roster: they are the clock, always.

The roster variance report puts the two side by side for a pay period: rostered hours against clocked hours per person and date, the difference, and a flag for a no-show on a rostered day or a rest day worked. Only covered employee-dates appear — somebody on fixed planning has no plan to vary from, and the monthly attendance page already reports them.

Both the variance and any single roster export as CSV, and published rosters are readable over the REST API — the roster itself and any employee's governing shift plan, read-only, under a token carrying the Read rosters scope.

• Roster · View — the roster register, the planner grid read-only, the shift catalogue and the variance report.
• Roster · Manage — create and edit drafts, apply patterns, set coverage targets, auto-fill, publish, revise, assign open slots and maintain the shift catalogue.
• Staff need nothing beyond a portal login: their own shifts, availability, swaps and open-shift interest ride the ESS module.
• A swap's final sign-off runs through the ordinary approval engine, so who approves it is a routing question like any other.
• The whole module sits behind the EnableRostering setting. With it off the pages are not there, no plan is resolved, and every date behaves as it did before.

Worth remembering

• The roster changes what was expected of a date, never what was worked. Nothing here fabricates an hour.
• Published is immutable and the newest publication governs; the superseded one is kept because it is the record of what staff were told.
• An open slot is not cover. If the target says four and three are named, you are short three-quarters covered and one question.
• One shift per person per day, and one site per row: a day worked at another site is a deployment change, not a roster cell.
• Coverage advises, people decide — and the employee's voice never blocks the manager's call.