Full module reference: strategic rostering →
Lifecycles · The roster month
From a demand figure to a schedule staff actually work, in seven moves
A roster officer does not experience strategic rostering as a list of features. She experiences it as a sequence: decide what is needed, build something to test against it, let a solver try, correct what it gets wrong, check the result, publish it, and then watch it keep changing after publish. This page walks that sequence in order, with a link back to the full module reference at every stage.
Stage 1 of 7 · Demand
Before a shift exists, something has to say how many people are needed
A Manpower Requirement (MPR) is the demand side of the month: how many people, with which qualification, on which day. It exists before a single shift is drawn, and it is what the solver in stage 3 optimises against, not an empty grid a planner fills in by hand.
Sequence MPR
A fixed min/max per shift type: Morning needs 2 to 4, Night needs 1 to 2, every day of the cycle.
Weekly MPR
The same idea, but the number can differ by day of week: weekday Morning needs 4, weekend Morning needs 2.
Pattern-based MPR
Demand expressed against a whole reusable Shift Pattern, such as a 4-on/4-off rotation.
For every day and qualification, SkyRoster generates as many shift slots as the requirement's configured maximum, and marks the first of them, up to the minimum, as required. The rest sit above minimum as optional capacity. A time-boxed Specific Requirement can raise or lower the normal figure for a limited date range without replacing it, for a known high-traffic week.
Stage 2 of 7 · Draft
Two ways to start: a blank wizard, or a draft that remembers last month
A three-step wizard builds the draft: Roster Settings (unit, resource type, rotation strategy, roster type, date range, and one or more manpower requirements, chosen explicitly, none of them pre-selected), Staff Selection (which employees or teams, filterable by unit and qualification validity), and Constraints Settings (tune the rule set for this roster, or load one saved from an earlier setup). Finish opens the Workbench immediately, before the draft is even saved.
A brand-new draft
Starts from nothing but the manpower requirements and constraints chosen in the wizard. The right starting point for a genuinely new period, a new unit, or a rule change worth testing from scratch.
A continuation roster
Inherits its resourcing and constraints directly from an already-published baseline. The normal way to carry a rotation-based roster into its next period without re-configuring what has not changed.
Three choices made once, at the top of the wizard, resource type (individual or team), rotation strategy (a repeating pattern, or freely allocated day by day) and roster type (working, or an on-call preventive pool), combine into up to eight distinct roster shapes, each with its own solver variant underneath.
Stage 3 of 7 · Solve
A constraint solver, not a machine-learning model, and that distinction is the honest story
Solve dispatches SkyRoster's optimisation engine: a construction heuristic proposes a fast, roughly-feasible roster, then local search spends the rest of its time budget improving on it. Nothing here is trained on past data or guessing from a language model. It is a rule engine searching for the best-scoring arrangement against the exact constraints your unit configured.
It runs off to the side
A solve is dispatched asynchronously and the Workbench polls for the result, so a planner is never staring at a frozen screen. The default time budget is 240 seconds, with an early stop after 40 seconds of no improvement. configured
Two runs, two arrangements, one score
Solving is not deterministic. Run the same month twice and the concrete placements can differ, even though the score they reach does not meaningfully change. Judge the roster it hands back, not whether it reproduces an earlier run exactly. See what the engine is not for the full statement of that limit.
Stage 4 of 7 · Inspect and hand-edit
The solver proposes. A planner still has the last word on every cell
A solved draft is still a draft. A planner clicks any shift cell to open an assignment popover and pick a different shift type or qualification by hand, or works demand-first in the Position View, a grid organised by position and qualification rather than by employee, built for adding or removing slots and marking one required or optional.
A placeholder becomes a real shift
On a rotation roster, a flexible shift is a generic slot, not yet Morning, Afternoon or Night. Breaking the pattern into a concrete month converts each one into a real shift type, following a priority order configured on the manpower requirement. Full mechanism at strategic rostering.
Trainees, paired by rule, not by a second solve
An instructor's shift can carry trainees or support employees, added from the Workbench's Planning menu. Be precise about what this is: a rule-guided manual pairing on top of the separately-solved base roster, not its own optimised sub-solve. The full, honest statement of that limit →
Stage 5 of 7 · Check
Before publishing, ask the same question the solver asked, and get an answer in seconds
Check Solution reuses the identical scoring pipeline a solve uses, run with no search: it re-scores whatever is on screen right now, solved, hand-built, or a mix of both, and returns a Hard score, an Unassigned-shifts count and a Soft score, each one expandable into the specific rule, shift and person behind it. Nothing is re-optimised and nothing changes.
This is the moment stage 4's hand-edits get judged against the same rules the solver was judged against, so a planner never publishes on faith that a manual correction did not quietly break something three rules away. Full mechanism at Check Solution →.
Stage 6 of 7 · Publish
A publish gate with three strategies, and one of them is not the planner's call alone
Override
An in-place correction. The version number does not move.
Minor
The version ticks up by one. Still delegable to any authorised planner.
Major
The version rounds up to the next multiple of ten. A unit can require its head of unit to sign this one specifically. configured
A routine correction does not have to wait on anyone. A real overhaul cannot go live on one planner's signature if the unit decided it should not. Full statement of the gate at strategic rostering →.
Stage 7 of 7 · After publishing
The roster does not sit still. It keeps re-publishing itself
From the moment it is live, this baseline is what the operational day actually staffs against, see the operational day →. It also keeps changing on its own: an approved leave, duty, swap, work request or shift extension mutates the published baseline directly and re-publishes automatically. A planner does not reopen the wizard to keep the live schedule in sync with the world; only a genuinely new period, or a manual correction, brings them back to stage 4.
What a shift looked like before
Every published shift carries an append-only record of its own previous states, hover a shift after a republish to see what changed and roughly why. It is a real, useful trail, not a tamper-evident audit log. Full statement of that limit at /platform/limits.
Back to stage 2, on purpose
Once a baseline is live, a planner can generate a continuation draft for the next period directly from it, carrying resourcing and constraints forward rather than starting the wizard from a blank page again.
What this sequence does not promise
Read this before you assume more than it claims
Bring the month that fought you.
A working session runs these seven stages against your own demand, your own rules and your own headcount, not a canned example, so you see exactly where it would have landed.
Who else will ask, and what they will want