Working-time rules

Working-time rules are the boundary around every manual assignment, candidate suggestion, solved roster, and cover decision. Fivexer provides the rule engine and explanation format; you provide the values that apply to your operation.

No hidden legal defaults

Rules differ across countries, sectors, collective agreements, contracts, age groups, and dates. Fivexer therefore does not silently install a jurisdiction’s limits. An omitted rule is not checked.

Before using compliance results in production:

1. identify the rules and agreements that apply;
2. configure their actual values;
3. record worker-specific terms and exceptions;
4. review citations and outputs with the responsible legal or HR owner.

The product helps apply your rules consistently. It is not legal advice and cannot determine which rules apply to you.

Configure the planning clock

ts
await fivexer.roster.setSettings({
  timeZone: 'Europe/Tallinn',
  defaultTimeBudgetMs: 10_000,
  rules: {
    dailyRest: { minMinutes: 660 },
    weeklyRest: { minMinutes: 2_100, windowDays: 7 },
    workingTime: {
      maxPerDayMinutes: 600,
      rollingAverages: [{ maxMinutes: 2_880, windowDays: 7 }],
    },
    breaks: [
      { afterMinutes: 360, minMinutes: 30 },
      { afterMinutes: 540, minMinutes: 45 },
    ],
    consecutive: {
      maxWorkingDays: 6,
      forbiddenSuccessions: [{ fromTag: 'night', toTag: 'early' }],
    },
  },
});

Shift times are interpreted in timeZone, not in the browser’s zone. Overnight and daylight-saving transitions are resolved as real dated intervals before hours and rest are measured.

Time zone

Set it under Rules → Time zone. Shift times are wall clock — a 09:00 shift starts at 09:00 in the roster's zone — and the grid prints those digits without resolving anything, so a workspace left on the UTC default looks correct on screen and exports every shift at the wrong instant: a worker's Google Calendar shows a 09:00 Tallinn shift at 12:00.

A roster snapshots the workspace zone when it is drafted and keeps it, so changing the setting applies to rosters drafted from then on. Weeks already planned are moved deliberately: the panel counts them, names the drift in hours, and moves them on a click (rosters.update(id, { timeZone })), which re-projects their events into every connected calendar. The roster header shows the zone and, when it is not the reader's own, how far apart the two clocks are.

Public holidays

Set the workspace's holiday location under Rules → Public holidays (holidayCountry, and holidayRegion where a country's holidays differ by region). The platform resolves it to dates for every roster period and hands them to the engine as calendar.publicHolidays, so the Sunday-and-holiday rule, holiday fairness and the holiday pay premium all see the same days, and the grid names them. Dates typed into the pay setup are added on top. roster.holidays({ from, to }) returns the resolved list; roster.holidayLocations() lists the countries and regions the calendar covers.

What can be expressed

The scheduling engine supports rule families for:

• daily and weekly rest, including rolling windows and reductions;
• daily limits and rolling working-time averages;
• ordinary time, overtime caps, consent, and time off in lieu;
• contracted hours — a full-time week that part-time fractions are measured against, an optional hard cap over contract, and a reported shortfall; the solver plans every person with a contract towards their pro-rated period total;
• night-work bands, duration limits, averages, and hazardous-work caps;
• paid and unpaid break requirements;
• consecutive workdays, consecutive nights, and forbidden shift successions;
• Sunday, holiday, and minimum-engagement rules;
• publication and cancellation notice;
• availability, preferences, time off, and external commitments;
• date-valid qualifications and required team composition;
• per-contract hour and day limits;
• fairness across nights, weekends, hours, and other declared dimensions.

Worker-specific rules override workspace rules where the model supports them. This is how individual opt-outs, protected categories, hazardous-work status, or contract-specific limits are represented without weakening the rule for everybody else.

Severity and explanations

Validation returns structured issues:

Issues carry a stable rule code, plain-language message, affected worker or shift, measured actual, required bound, unit, and optional citation. Render those values; do not reduce a verdict to a red dot.

Fairness and cost never overrule legality

The solver evaluates hard feasibility before soft objectives. Cost and fairness can choose between otherwise acceptable plans, but they cannot make a prohibited assignment legal or trade an unfilled mandatory slot for a saving.

The roster engine is also deliberately separate from task-routing learning. It does not consume acceptance history, predicted reliability, no-show risk, or behavioural scores. Candidate ranking uses declared planning facts and realised fairness counts only.

See validate and publish for how rules appear in the approval workflow.