Reference · built on requestOperator by FibricWorkforce & scheduling

Schedule Notice

Checks schedule changes against the notice window in the site's fair-scheduling rules and proposes a consent request or premium record.

Request accessPricing ↗

About

Schedule Notice is an operator job for sites covered by fair-scheduling or predictable-scheduling rules. It reads every change to a published shift from your scheduling system: a shift added, moved, shortened, or cancelled, and when the change was made. It compares the change time and the shift's start against the notice window you set for the site.

A change inside the window becomes one of two proposals. A consent request to the employee, sent through Slack or Microsoft Teams, where your rule lets an employee accept a change. Or a premium record for payroll, with the shift before and after and the hours of notice given, for a manager to approve.

This is a reference listing. It documents what Fibric would read from Schedule Notice 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

  • Published shifts and their changes: 7shifts shifts with modified_since, When I Work shift history with a reason code and who changed it, Deputy roster webhooks
  • Shifts deleted after publication: Homebase deleted shift IDs by date range, When I Work shifts with deleted_ids for a window
  • When a schedule was published: the 7shifts schedule.published webhook, Deputy roster publish, published_date on a When I Work shift
  • Each employee's home site and its rule: the work location from BambooHR or Rippling, or the site table in the operator's configuration
  • Consents already given: replies to the operator's own requests in Slack or Microsoft Teams
  • Premium codes payroll accepts: pay adjustment codes in Dayforce, a Pay Data batch in ADP Workforce Now, or a Paylocity payroll batch

Proposed actions

  • Target capability: propose a consent request to the employee for a change inside the notice window, with the shift before and after
  • Target capability: propose a premium record for payroll: a Dayforce EmployeePayAdjustment with IsPremium, or a pay data line for ADP Workforce Now or Paylocity
  • Target capability: propose holding a draft change until it falls outside the window, as a note to the scheduler before the schedule publishes
  • Target capability: propose a weekly log per site of changes inside the window, with the consent or premium recorded for each

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

What you can build

  • Log When I Work changes against a notice window

    Shift history gives every change with its reason code and time. Changes inside the window become a consent request in Slack or a premium proposal, as the site rule says.

    With When I Work, Slack

  • Catch 7shifts changes after publish

    Shifts with modified_since after schedule.published are compared with their start. The operator proposes a Dayforce pay adjustment with IsPremium where the notice fell short.

    With 7shifts, Dayforce

  • Read Deputy roster webhooks

    Roster update and delete webhooks arrive as changes happen. For a published roster changed inside the window, the operator proposes a consent request in Microsoft Teams.

    With Deputy, Microsoft Teams

  • Send premiums to Paylocity

    Homebase shifts and deleted shift IDs are polled per location. Cancellations inside the window become a pay entry import line for the manager to approve.

    With Homebase, Paylocity

Requirements

  • A scheduling connector that exposes change times or history for published shifts: 7shifts, When I Work, Deputy, or Homebase
  • A notice window and rule per site, set in the operator's configuration
  • Slack or Microsoft Teams for consent requests and manager approval
  • Optional: a payroll connector for the premium line, such as Dayforce or Paylocity
Authentication
Holds no credentials itself. Schedule changes are read and premiums proposed through the connectors you bind, with the access you granted each.

Limits

  • It applies the window you configure per site. It holds no table of fair-scheduling law by city or state, and reads none
  • When I Work shift history covers a rolling 90 days from the shift start; older changes cannot be reconstructed
  • Homebase documents no webhooks, so a change there is found on the next poll, and the change time is at worst the poll time
  • A consent counts only when it arrives through a channel the operator reads. An agreement on the floor is entered by the manager

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 Schedule Notice ↗

Questions and answers

Who approves what?
The employee answers a consent request: accept or decline the change. The manager approves a premium record before it goes to payroll, seeing the shift before and after, the notice given, and the rule. Neither happens without an answer.
What is logged for each change?
Per change: the shift before and after, who changed it and when, the notice in hours, the rule applied, the consent request and reply or the premium as approved, and the payroll write with its response.
Does it stop a manager changing a schedule?
No. Managers change schedules in the scheduling system as before. The operator watches the change, asks for consent or proposes a premium, and keeps the log. It never reverts a change.
Ask about Schedule Notice

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy