• Administrator

Shift types

The shift type's shell and versions, the punch settings, automatic detection, changing a single day's type by hand, and how a night shift is expressed.

Updated

A shift type tells you what kind of day this is: when it starts and ends, what the target is, how breaks are calculated and how punches are handled. The same type serves two uses: the planned shift inherits its frame from it and the actual working day is calculated with its rules.

Types are managed under SettingsWork time & rulesShift types.

Shell and version

A shift type has two levels. The shell is a permanent identifier: code, names (fi/sv/en), short code and colour.

The version carries the day-specific calculation parameters:

  • the frame, meaning the start, the end and the target
  • the break and lunch policy
  • the cap on the paid coffee break
  • the flexitime window
  • the day’s overtime parameters
  • the default hour type

A version is always valid over a specific interval. When a rule changes, the old version is not edited; a new version is created with a new validity interval. That way the calculation for old weeks does not change retroactively.

The version in use is locked at the moment of use. For a shift the version is locked as soon as you paint it, and for a day at confirmation. Later editing of the type does not change published shifts or confirmed days; it only takes effect from that point onwards.

Punch

In the Punch section you define how punches turn into a day:

  • Punch rounding
  • Grace at start (min) and Grace at end (min)
  • Open-punch auto-close: No auto-close, At the work-day boundary or At the planned end

Where the rule comes from when a field is empty

An empty field is inherited; it does not mean zero. The value is taken first from the work-time model’s default type and ultimately from the statutory default. The day breakdown shows where the rule came from: from shift, from model or statutory.

So fill in only the fields where the type differs from the model.

How the day’s shift type is chosen

Every day resolves to exactly one shift type. The resolution runs in order and the first hit wins:

  1. a type chosen by hand for that day
  2. the person’s published shift
  3. the group’s published shift
  4. the clock-time window, meaning the start time of the day’s first entry
  5. the work-time model’s assignment rule (weekday or date)
  6. the work-time model’s default type

Step 4 also works in the worktime calendar. When the hours are recorded by hand, the detection reads the start time of the day’s first entry exactly as it reads a punch-in — no separate shift plan is needed. The windows are set in the work-time model’s assignments (SettingsWork time & rulesWork-time models).

The day breakdown states where the type came from: Planned shift, Detected from the clock time, From a rule, Model default or Changed by hand.

Changing a day’s type by hand

When the automation gets it wrong — for instance in flexitime work, where shifts are not planned at all — a single day’s type can be changed in the day breakdown under Shift type. The choice applies to that day only, and the Automatic option hands the day back to the automation.

The change is shown to the approver in the day’s details as the line Shift type changed by hand, so the deviation is not missed. It creates no extra approval step.

Who may change it is decided under SettingsRecording policiesChanging a day’s shift type. The options are the employee and their supervisor, the supervisor only, or nobody. The same choice can be made per staff group, so the flexitime group may change it while the rostered group may not — in one and the same organisation. Automatic detection always works, even when changing by hand is turned off.

A confirmed day is not changed in place. Reopen the day for editing first, change the type and confirm again. If the chosen type has no version in force on that day, the day is calculated by the automation and the breakdown says so.

Night shift

The end of a shift is measured in minutes from midnight of the starting day, so over 1440 means the following day. A 22:00–06:00 night shift is therefore 1320–1800. The end is always greater than the start, and no separate “next day” flag is needed.

If something goes wrong

A shift needs different times just once. Do not create a new type. A planned shift chooses a shift type and inherits its frame and its policies, but a one-off frame can still be adjusted on an individual shift.

I changed the type, but an old day still calculates with the old rule. That is by design. A confirmed day keeps the version locked into it. The change affects the days that are confirmed while the new version is valid.

The payroll outcome does not match the type’s parameters. A shift type gives payroll parameters, but the interpretation is determined by the collective agreement. Check the interpretation in the collective agreement.

See also Work-time models and Enable the punch clock.

Was this guide helpful?

Related

Waitlist