Skip to content
SkyRosterBook a working session

Platform · Strategic rostering

Build the month, then publish it through a gate that knows how much changed

Strategic rostering is where a month of shifts gets built: demand goes in as a manpower requirement, a constraint solver proposes an assignment, a planner corrects what it gets wrong, and a publish gate decides whether one signature is enough. This page covers the mechanism end to end, including the parts that are still a manual, rule-guided step rather than something the solver optimises on its own.

The lifecycle

  1. 1

    Wizard

    Pick the unit, resource type (individual or team), rotation strategy, roster type and date range, then attach one or more manpower requirements.

  2. 2

    Draft

    An editable, unpublished template. Solve it, hand-place shifts, or mix both, and no one outside the planning team sees it yet.

  3. 3

    Solve / Check

    Solve dispatches the optimiser. Check Solution re-scores the roster exactly as it stands, in seconds, without changing an assignment.

  4. 4

    Publish

    The draft becomes the baseline staff actually see. Every save picks a version strategy: Override, Minor or Major.

  5. 5

    Continuation

    Generate next period's draft directly from a published baseline, carrying its resourcing and constraints forward instead of starting blank.

Once a baseline is live, ordinary operational events (a leave approval, a duty approval, an approved swap, an extra shift) mutate it and re-publish automatically. A planner does not reopen the wizard to keep the live schedule in sync with the world; only building a genuinely new period, or correcting the roster by hand, brings them back into the draft/publish loop above.

Demand before shape

The manpower requirement decides what the solver is even trying to satisfy

Before a shift exists, the planner has told SkyRoster how many people, with which qualification, are needed on which day. That demand, the Manpower Requirement (MPR), is what the solver optimises against, not an empty grid a planner fills in by hand.

Sequence MPR

A fixed min/max headcount per shift type: Morning needs 2 to 4 people, Night needs 1 to 2, the same figure 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, rather than shift by shift.

For every day and qualification, the system generates as many shift slots as the requirement's configured maximum, and marks the first of them, up to the configured minimum, as required. The remainder sit above minimum as optional capacity, visible in a demand-first grid (the Position View) rather than buried inside each employee's own row. A time-boxed Specific Requirement can also raise or lower the normal figure for a limited date range, layered on top rather than replacing it.

Two axes, chosen up front

Rotation or no rotation, individual or team: the roster's shape is a decision, not a default

Rotation strategy

Shift Rotation: staff follow a predefined repeating pattern (say, 4-on/4-off), and the solver places multi-day blocks rather than individual shifts. No Rotation: the solver freely allocates shifts day by day purely to meet the manpower requirement and the active rules, with no fixed repeating sequence.

Resource type

Team-based: the solver allocates whole teams to shifts. Individual-based: it allocates individual employees. A Team roster can later be broken down into an Individual one using the same shift-conversion mechanism described below, for a fairer, more granular distribution once the team-level shape is settled.

A third choice, Roster type, sets Working (the normal staffed schedule) against Preventive (an on-call roster: a defined pool is reachable and obliged to report if called in, without being on a working shift). The three axes combine into up to eight distinct roster shapes, each with its own solver variant.

Solver variantConstraint checks wired in
No rotation, individual employee roster60 verified
No rotation, backup-employee roster59 verified
Rotation, individual employee roster28 verified
Rotation, backup-employee roster30 verified
Rotation, team roster8 verified

A rotation roster has less to check per placement (it is moving a pre-shaped block, not an individual shift), which is why its constraint counts run lower than the no-rotation variants. The full, current catalogue of rule display names is compiled from the product on every build: /engine/rules.

Flexible and extra shifts

A placeholder that becomes a real shift, and a shift that was never planned at all

Flexible shifts

A flexible shift is a generic placeholder inside a rotation pattern, not yet Morning, Afternoon or Night. When a planner breaks the pattern into a concrete monthly roster, each flexible slot converts into a real shift type according to a conversion list configured on the manpower requirement. This lets a unit define one reusable pattern, such as 4-on/4-off, without hard-coding which exact shift fills the flexible slot every time.

Conversion respects a configurable priority order you set on the requirement, and the solver has a dedicated rule that nudges it toward your higher-priority target when more than one valid conversion exists. It does not apply to the Trainee roster, which always runs without a conversion context.

Extra shifts (Work Requests)

Beyond the planned roster, a planner can open an employee's rest-day cell directly in a published roster, pick a qualification the day's demand calls for, and place them on it. On approval, which can be configured to auto-approve or require an acceptance step, the cell updates in place with its own icon and re-publishes automatically into the live baseline.

It is fully reversible: an approved work request can be revoked directly from the Workbench, which reverts the published roster and logs the reversal. This is the mechanism behind calling someone in to cover an unplanned gap without touching the rest of the month or re-running the solver.

Trainees, support and instructors

A trainee is paired to an instructor's shift by rule, not by a separate solve

SkyRoster models on-the-job training and substitution directly on the roster, not as a bolted-on separate system. An instructor's shift can carry a list of trainees or a list of support employees, never both at once on the same shift.

What is a real, enforced rule

Mutual exclusion between trainee and support on one instructor shift is enforced in the UI. The maximum number of trainees a single instructor can carry at once is a dedicated, configurable solver rule: "One instructor supervises only so many trainees".

What a lock overrides

A shift the planner has explicitly locked always wins. If an automatic trainee or support pairing would conflict with a locked shift, that person's write for that day is simply skipped, rather than overriding the lock or creating an invalid dual assignment.

What gets recorded

A resource-day record is generated for everyone on the shift, instructor plus every trainee and support employee, so a single instructor shift with three support employees produces four separate records for reporting and history.

After publishing

Change history: what a shift looked like before

Every published shift carries an append-only record of its own previous states: the template version at the time, a timestamp, and, usually, a reason such as leave approval, swap approval or manual publish. Hovering a shift after a republish shows what it looked like before the change.

It is a real, working "what changed and roughly why" trail, useful the day a controller or a head of unit asks why their Tuesday moved. It is not a tamper-evident audit log: there are documented gaps in how reliably it survives concurrent edits and how specific the recorded reason always is. The full statement of that limit, and what to do about it, is on /platform/limits.

Customer-facing change-history access is part of Audit & History, included in SkyHeavy or available as an add-on. Internal history used by rostering workflows continues independently of that entitlement.

Publishing

The publish gate: three version strategies, and one of them is not the planner's call alone

Override

An in-place correction. The version number does not move. Any authorised planner can do this.

Minor

The version ticks up by one. Still delegable to any authorised planner.

Major

The version rounds up to the next multiple of ten, so publishing Major from version 23 produces version 30. A unit can require its head of unit to sign this one specifically. configured

This is a governance control, not a formality: a routine correction does not have to wait on anyone, and a real overhaul cannot go live on one planner's signature if the unit decided it shouldn't. The version number itself is a quick, at-a-glance read on how significant a past change was.

Vocabulary

Terms a planner uses that a spreadsheet does not have

MPR
Manpower Requirement. The demand side: how many people, with which qualification, on which day.
Baseline
A published roster. The version staff actually work against, edited from then on through the Workbench.
Continuation roster
A new draft generated from an already-published baseline, inheriting its resourcing and constraints.
Check Solution
Re-scores the current roster against every active rule without re-optimising or changing anything.
Chunk
A multi-day block the solver places as one unit on a rotation (pattern-based) roster, rather than shift by shift.
Version strategy
Override, Minor or Major: how much a publish changes the roster's version number, and who is allowed to do it.

What this module does not do

Read this before you assume more than it claims

Bring us a month that went wrong.

A working session is 45 minutes with your own roster on screen, not a canned demo. Bring a pattern that fought you and we will walk through what the engine would have done with it.

Book a working sessionSend a question instead

Who else will ask, and what they will want