EN RU PL
Back to IceFleet

Shift patterns, protections, and conflicts

Updated: August 29, 2026

Shift Patterns is an optional module — if you don't see it in your menu, it isn't turned on for your company yet (see the troubleshooting article on module visibility).

Creating a pattern

A pattern is a named cycle (e.g. a "5/2" rotation) with a cycleLengthDays and per-day-of-cycle start/end times. Validation on save:

  • Cycle length must be a positive number.
  • Each day's index must fall within the cycle length.
  • Each day's end time must be after its start time.

Then you assign workers to the pattern: worker + location + optional position + a start date + optional end date. A generator creates the actual schedule rows going forward automatically from that.

Assignment overlap is rejected outright

A worker can't have two active pattern assignments with overlapping date ranges — creating or editing one that overlaps another fails immediately with "EMPLOYEE_HAS_OVERLAPPING_ASSIGNMENT". There's no silent merge: end the old assignment (set its "effective to" date) before starting a new overlapping one. Assigning a dismissed worker to a pattern is rejected the same way, with "EMPLOYEE_DISMISSED".

The most important rule: manually_modified protection

Once you hand-edit a single day's generated shift — or once that day is already in the past — the system will never touch that specific day again. Not to add or remove workers, not to recompute the envelope time, nothing. This is deliberate: it protects your manual correction from being silently overwritten the next time the pattern regenerates.

Practical implication: if you manually adjust one day's shift, future pattern or assignment changes will not automatically ripple into that one day anymore — you'll need to keep editing it by hand from then on. This is also why editing a pattern's hours (keeping the same day index) immediately recalculates and regenerates every future, unprotected shift fed by that pattern — but leaves any day you've already hand-edited alone.

Conflicts

If a worker marks themselves unavailable on a day where a pattern already generated them a shift, the system does not remove the shift — it stays on the schedule, flagged as a conflict, and you (or whichever manager owns that location) get notified. Check the pattern page's conflicts list regularly if you rely heavily on patterns — that's where every flagged slot in the generation window shows up, waiting for you to reassign or resolve it. You can turn conflict notifications on or off for yourself.

Settings worth knowing

  • Auto-extend and generation horizon (how many days ahead shifts get generated) are configurable — pushing the horizon past the allowed maximum returns "HORIZON_DAYS_OUT_OF_RANGE".
  • There's currently no "completed" status on a schedule entry — completion is tracked separately on the active-shift side, and past schedule rows are physically cleaned up a few minutes after they pass. Not something you manage, just useful to know if an old row seems to vanish.