# 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:

| Capability | Question it answers | Unit of work |
| --- | --- | --- |
| Task routing | Who should take this request now? | Ticket, case, visit, job |
| Rostering | Who should work this shift on this date? | Dated shift occurrence |
| Scheduled task | When may this task enter routing? | Task held until `schedule.notBefore` |

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

```
textSite (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](/docs/rostering/sites-posts-shifts/). If your operation is already configured, go directly to [building a roster](/docs/rostering/build/).

## 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](/docs/rostering/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.