How to Send Slack Notifications for Schedule Changes

Alert your team on Slack when shifts are added, changed, or cancelled in Deputy.

What This Integration Does

Schedule changes that don't reach the affected employees turn into missed shifts and angry texts. This workflow polls Deputy on a tight cadence, compares the current roster with the last known state, and posts targeted Slack messages whenever something has changed - new shifts, edited start times, swapped employees, or cancellations. Managers get an at-a-glance ops channel, and individual employees can be tagged directly so they see updates that affect them.

It runs on a fast schedule (every 15 minutes is typical), stores the last seen roster as workflow state, and emits one Slack message per detected change. Because it's diff-based, it only notifies on actual edits - it won't spam the channel if nothing changed.

Prerequisites

A deputy connection with read access to rosters and employees.
A slack connection with permission to post in your operations channel and to look up users by email.
Either a mongodb connection or another small store for keeping the "last known roster snapshot" between runs.
Employees in Deputy should have email addresses that match their Slack accounts so individual tagging works.

Step 1: Schedule Trigger

Add a Trigger node and set its type to Schedule. Every 15 minutes is a good default - fast enough that employees get told about changes promptly, slow enough not to hammer Deputy's API. If you only care about same-day changes, you can bump it to every 5 minutes during operating hours and pause overnight using a Condition on the trigger time.

Step 2: Fetch the Current Roster

Add a Connector node pointing at the deputy connector with list-rosters. Filter to the next 7 days (or whatever planning horizon matters - past shifts can't change for most ops) and only the locations covered by the Slack channel. In parallel, fetch deputy list-employees so you can map employee IDs to names and emails for Slack tagging.

Step 3: Load the Last Known Snapshot

Add a Connector node pointing at the mongodb connector with find-documents. Read the most recent snapshot from a collection like deputy_roster_snapshots. On the first run there won't be one - your downstream Condition node should treat "no previous snapshot" as "no changes to report, just record the baseline".

Step 4: Transform - Diff Current vs Previous

Add a Transform node (or use the code connector's execute-javascript tool for clarity) that produces three arrays:

added - shifts in the current roster with no matching ID in the previous snapshot.
removed - shifts in the previous snapshot that are gone now.
changed - shifts where the ID matches but start time, end time, or assigned employee differs.

Each entry should carry enough context to write a useful Slack message: employee name, location, old vs new times, and the change type.

Step 5: Notify on Slack

Wrap a Loop node around the combined diff array. For each change, call slack send-message with a templated body, for example:

:calendar: *Schedule update*
{{ change.employeeName }} - {{ change.locationName }}
{{ change.type }}: {{ change.oldStart }} -> {{ change.newStart }}

For per-employee mentions, use slack lookup-user-by-email to resolve the employee's Slack user ID from their Deputy email, then include <@{{ slackUserId }}> in the message body. Route cancellations and same-day edits to a higher-urgency channel using a Condition node.

Step 6: Save the New Snapshot

Add a final Connector node pointing at the mongodb connector with insert-documents (or update-documents with upsert). Write the current roster back to the snapshot collection along with a timestamp so the next run has a baseline to diff against. Skip this step if you're still treating the run as a baseline capture (no previous snapshot existed).

Tips

Bound the diff window. Only diff the next 7 days; old shifts shouldn't generate notifications.
Throttle bulk reschedules. If 50 shifts change at once (typical when a manager republishes a roster), post a single summary message and a thread of details instead of 50 separate channel messages.
Quiet hours. Use a Condition on the trigger time to suppress non-urgent notifications between, say, 22:00 and 06:00.
Audit trail. Keep snapshots for 30 days so you can replay any disputed schedule change.

Common Pitfalls

Race with manual edits. If a manager is still editing the roster in Deputy when the workflow polls, you may see partial changes. A 15-minute cadence is usually slow enough to avoid this; faster cadences need a debounce.
Email mismatch. Deputy and Slack often have different employee emails. Build a small mapping table rather than failing silently when lookup-user-by-email returns nothing.
Timezones. Display Slack messages in the location's timezone, not the workflow's. Pass the location timezone through and format with the date connector's format tool.
First-run flood. Without the "no snapshot = baseline only" guard, your first run will announce every shift in the roster as "added". Always capture before notifying.

Testing

Run the workflow manually once to capture a baseline snapshot, then make a single test change in Deputy (move one shift by 15 minutes) and re-run. You should see exactly one Slack message describing that change. Once the diff logic is sound, turn the schedule on.