How to Sync Deputy Shifts to Monday.com
Keep your Monday.com project board updated with Deputy scheduling data.
What This Integration Does
Project managers planning sprints, deliveries, or installs need to know who's actually working when. That data lives in Deputy, but project managers live in Monday. This workflow runs daily, pulls each employee's published shifts from Deputy for the upcoming planning window, and writes (or updates) one item per shift on a Monday staffing board. Project leads see availability without ever leaving Monday.
The sync is idempotent. Each Monday item is keyed by Deputy roster ID, so the workflow upserts rather than appending. Re-runs are safe, and a shift cancelled in Deputy will be removed from Monday on the next run rather than leaving a stale ghost.
Prerequisites
- A deputy connection with read access to rosters, employees, and locations.
- A monday connection with create/update access to the target board.
- A Monday board with columns for: employee name, shift date, start time, end time, location, and a hidden column storing the Deputy roster ID (used as the upsert key).
- The Monday board ID and the column IDs - grab these via monday
list-boardsandget-boardonce before building.
Step 1: Schedule Trigger
Add a Trigger node and set its type to Schedule. Daily at 05:00 in your operations timezone is a good default so the Monday board reflects the latest publish before standups. Bump to twice daily (05:00 and 13:00) if your scheduling team makes frequent intra-day edits.
Step 2: Compute the Planning Window
Add a Variable assignment using the date connector:
windowStart- today vianow+start-ofwith unit "day".windowEnd- 14 days from now usingadd.
Two weeks is a typical project planning horizon. Adjust to match how far ahead your project managers want visibility.
Step 3: Fetch Deputy Rosters
Add a Connector node pointing at the deputy connector with list-rosters. Filter by windowStart / windowEnd. In parallel, fetch deputy list-employees and list-locations so you can render readable names rather than IDs on the Monday item. If your roster spans many locations, scope this query to the ones the Monday board covers.
Step 4: Transform - Shape Shifts for Monday
Add a Transform node that joins each roster with the matching employee and location, producing one record per shift in Monday's column schema:
{
"deputyRosterId": "{{ roster.id }}",
"itemName": "{{ employee.name }} - {{ location.name }}",
"columnValues": {
"date": { "date": "{{ roster.date }}" },
"start": { "text": "{{ roster.startTime }}" },
"end": { "text": "{{ roster.endTime }}" },
"location": { "text": "{{ location.name }}" },
"employee": { "text": "{{ employee.name }}" },
"ext_id": { "text": "{{ roster.id }}" }
}
}
Use Monday's column IDs (not column titles) as the keys inside columnValues.
Step 5: Upsert into Monday
Wrap a Loop node around the transformed shifts. For each shift, first call monday list-items filtered by the ext_id column equal to deputyRosterId. Use a Condition node to branch:
- No match: call monday
create-itemwith the item name and column values. - Match exists: call monday
update-itemto refresh times, employee, or location.
This upsert pattern keeps the board clean across multiple daily runs.
Step 6: Clean Up Cancelled Shifts
After the upsert loop, run one more pass: query Monday for all items in the planning window, find any whose ext_id isn't in the current Deputy roster set, and call monday delete-item on them. This is what removes shifts that were cancelled in Deputy after the last sync. On failure (Monday throttling, network error), route to a slack send-message alert so on-call sees the break.
Tips
- Use the column-ID lookup once. Monday returns column IDs from
get-board; pin them in a workflow variable rather than hardcoding strings everywhere. - Batch where you can. Monday's
raw-graphqltool supports multi-mutation calls if the per-item create starts to feel slow. - Project the columns. If your Monday board has dozens of columns, only write the ones owned by this sync so other automations and humans can edit the rest without conflict.
- Tag the items. Add a "source: deputy" tag column so it's obvious which items the workflow owns versus which were created manually.
Common Pitfalls
- Two-way sync surprises. If a project manager edits an item on Monday, the next Deputy sync will overwrite their change. Be explicit that this is a one-way sync, or move human edits to a separate column the sync doesn't touch.
- Timezones. Deputy returns times in the location's timezone. Monday's date columns are timezone-naive; store the location timezone in a separate text column so users know what zone the times mean.
- Pagination.
list-rosterscaps per page. Loop until the result page is empty rather than relying on a single call when you have many locations or a long window. - Deleted items reappearing. If a manager deletes an item on Monday by hand, the next sync will recreate it because Deputy still has the roster. If manual delete should be sticky, store deleted IDs in MongoDB and skip them in the upsert.
Testing
Run the workflow manually with a 2-day planning window and a single location first. Inspect three or four items on the Monday board against the Deputy UI and confirm names, times, and the hidden ext_id column match. Then expand the window to 14 days and turn the daily schedule on.