Rostering overview

Fivexer rostering turns recurring staffing demand into a dated, explainable plan. You describe where work happens, which posts must be covered, when each shift runs, who may work it, and which working-time rules apply. Fivexer can then help you assign people, check a hand-built plan, or solve the whole period.

Rostering and task routing answer different questions:

A worker being rostered for Tuesday does not by itself put them on shift in the live router. Rosters are the plan; worker availability is live presence. Keep that separation when integrating the two.

The domain model

text
Site (a geographic place)
└── Post (something at that site that must be covered)
    └── Shift band (a reusable time span)
        └── Shift template (the required cover on selected days)

Planning period
└── Roster
    └── Shift occurrence (one template on one date)
        └── Assignment (one worker on that occurrence)

• A site is a building, depot, ward, or customer location. Travel rules operate between sites.
• A post is an operational responsibility: reception, north ward, patrol van 2, or opening supervisor. The API calls it a station; the console calls it a post.
• A shift band is a named time span such as Day, Late, or Night.
• A shift template combines a post, band, weekdays, headcount, and qualification requirements.
• A shift occurrence is a dated instance with the stable ID <templateId>@<date>.
• A roster is a versioned plan for a date range. It starts as a draft and becomes visible to workers only when published.

The normal workflow

1. Set the roster time zone and the rules you actually enforce.
2. Add people and record their terms, qualifications, sites, and approved time off.
3. Define sites, posts, shift bands, and the cover required in each grid cell.
4. Create a roster for a planning period.
5. Assign manually, ask Fivexer to solve, or mix both approaches.
6. Validate the draft and inspect why a person can or cannot take a shift.
7. Run publishing preflight, resolve warnings, and publish a named version.
8. Handle later absence through the cover workflow without rebuilding the whole roster.

Start with sites, posts, and shifts. If your operation is already configured, go directly to building a roster.

What Fivexer decides—and what it does not

The solver uses declared qualifications, availability, approved leave, contractual limits, working-time rules, cost, travel, and fairness. It does not rank workers using reliability scores, no-show prediction, acceptance history, or learned behavioural profiles.

Fivexer also ships no country’s legal limits as defaults. Working-time numbers vary by jurisdiction, sector, agreement, and person. A blank rule is not checked; a configured rule is enforced and explained. See working-time rules.

Drafts are safe to explore

Roster edits create versions. Validation is read-only, candidate explanations do not assign anyone, and solving creates a result version rather than silently publishing it. Workers see a roster only after an explicit publish action. That makes it safe to compare a manual plan with a solved one before choosing what becomes official.