Reference · built on requestOperator by FibricWorkforce & scheduling

Shift Rest

Checks scheduled and actual shifts against minimum rest, consecutive-shift, and shift-length rules and proposes a change.

About

Shift Rest is an operator job that reads a schedule the way a rule would. It takes the shifts scheduled for each employee and the shifts they actually worked, from punches, then checks three things you configure per site or contract: the minimum gap between one shift's end and the next start, the most consecutive days or shifts allowed, and the longest a single shift may run. An actual shift that ran late counts against the next scheduled start.

Where a scheduled shift breaks a rule, it proposes a change: a later start, a shorter shift, or a swap with an eligible colleague. The scheduler approves the change in Slack or Microsoft Teams, and it is applied to the schedule once, with the rule and the shifts that triggered it on the record.

This is a reference listing. It documents what Fibric would read from Shift Rest and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Scheduled shifts per employee: 7shifts shifts, When I Work shifts, Deputy rosters, Quinyx shifts by group and employee, Dayforce EmployeeSchedules
  • Actual shift boundaries from punches: 7shifts time_punches, When I Work times, Deputy timesheets, Dayforce EmployeePunches
  • Consecutive-day settings where the system holds them: 7shifts labor_settings with consecutive_days_threshold
  • Employee attributes a rule can depend on: age, contract type, or agreement, from BambooHR, Personio, or Deputy employee agreements
  • Colleagues who may take a shift: When I Work eligible users and swapusers, Deputy rosters available for swap
  • Schedule changes as they are made: the 7shifts schedule.published webhook, Deputy roster webhooks, When I Work shift history

Proposed actions

  • Target capability: propose a change to the scheduled shift that breaks a rule: a later start, an earlier end, or a shorter shift
  • Target capability: propose handing the shift to a colleague the rule allows, as a When I Work swap request or a Deputy RosterSwap
  • Target capability: propose a note to the scheduler before publish, listing draft shifts that would break a rule once published
  • Target capability: propose a weekly list per site of rule breaks that already happened, built from actual shifts, for review

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Check When I Work schedules before publish

    Unpublished shifts are read with supervisor rights and set against times already worked. Shifts inside the minimum gap are listed for the scheduler in Slack with a later start proposed.

    With When I Work, Slack

  • Apply a consecutive-days limit from 7shifts

    consecutive_days_threshold from labor_settings and shifts per user give the run of days. The operator proposes a swap for the shift that would exceed it, applied with Update Shift once approved.

    With 7shifts, Microsoft Teams

  • Use Deputy agreements for contract rules

    Employee agreements give the contract type; rosters and timesheets give scheduled and actual shifts. The operator proposes a RosterSwap or a roster change for the shift that breaks the contract's gap.

    With Deputy, BambooHR

  • Read Quinyx shifts by group

    Shifts by group and employee are checked against the site rule. The operator proposes a shift change for the scheduler and posts it to Microsoft Teams.

    With Quinyx, Microsoft Teams

Requirements

  • A scheduling connector with shifts per employee: 7shifts, When I Work, Deputy, Quinyx, or Dayforce
  • A time and attendance source with punches, so actual shift ends are known
  • Rules per site or contract: minimum gap, consecutive limit, and maximum shift length, set in the operator's configuration
  • Slack or Microsoft Teams, where the scheduler answers
Authentication
Schedules and punches are read, and changes proposed, through the connectors you bind, under the access each connector holds; none of that access is the operator's own.

Limits

  • Rules are yours to set. The operator carries no working-time law by country and applies only the values you configure
  • A rule that depends on age or contract needs that field from an HR connector; without it the site default applies
  • It checks the shifts it can see. Shifts at a second employer, or in a scheduling system not bound, are unknown to it
  • Where a swap waits on the colleague's acceptance, the schedule stays as it was until they answer, and the operator says so

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Shift Rest ↗

Questions and answers

What is put in front of the scheduler?
A change to one shift: the employee, the rule broken, the shifts that break it, and the change proposed, with a colleague named if it is a swap. The scheduler approves, edits, or declines. The schedule stays as it was until then.
What does it leave on the record?
The rule, the scheduled and actual shifts it was checked against, the proposal, the approval with name and time, the change as the scheduling system accepted it, and how to reverse it.
Does it change a shift on its own?
No. Every change is a proposal. It also does not clock anyone out or end a shift that is running long; it reports the actual shift afterwards and adjusts the next proposal.
Ask about Shift Rest

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.