How to Create Monday Items from Deputy Leave Requests

Build a Spojit workflow that polls Deputy for new leave requests on a schedule and creates a tracked item per request on a Monday.com leave-management board.

What This Integration Does

HR and operations teams need a single, visible place to track who has requested time off, when, and whether it has been actioned. Deputy holds the leave requests, but managers and approvers often live in Monday.com. This workflow closes that gap: on a fixed schedule it reads the latest leave requests from Deputy and turns each one into an item on a Monday.com board, so every pending request shows up as a row your team can sort, assign, and update without anyone re-keying dates by hand.

The run model is a Schedule trigger that fires on a Unix cron expression (for example every 15 minutes during business hours). On each run, Spojit calls Deputy to list current leave requests, filters out the ones it has already pushed, and creates a new create-item on your Monday.com board for each remaining request. The workflow leaves Deputy untouched (read-only) and only writes to Monday.com. Because it re-reads the full leave list each run, the deduplication step (described below) is what stops the same request from creating duplicate items on re-runs.

Prerequisites

A Deputy connection in Spojit (Connections → Add connection → Deputy) with permission to read leave records.
A Monday.com connection in Spojit with permission to create items on the target board.
The numeric boardId of your Monday.com leave-management board, and the column IDs for any fields you want to populate (for example a date column and a status column). Use the Monday.com list-boards or get-board tool once to read these IDs.
One Monday.com text or long-text column reserved to store the Deputy leave ID. This is what the workflow uses to avoid creating duplicates.
A timezone for the schedule (an IANA name such as Australia/Sydney).

Step 1: Start with a Schedule trigger

Create a new workflow in the Spojit designer and set the Trigger node type to Schedule. Add a 5-field Unix cron expression and a timezone. To poll every 15 minutes between 8am and 6pm on weekdays, use:

0,15,30,45 8-18 * * 1-5

Set the timezone to your team's IANA zone, for example Australia/Sydney. A single Schedule trigger can hold more than one cron line if you need irregular timing. The trigger output is {{ scheduledAt }}, which you can use later as a "synced at" timestamp on the Monday.com item.

Step 2: List leave requests from Deputy

Add a Connector node in Direct mode, choose the Deputy connector, and select the list-leave tool. This tool takes no inputs and returns the current set of leave requests. Name the node output something clear such as leave so downstream nodes can reference {{ leave }}.

Each leave record carries fields like the employee, start date, end date, and status. You will map these into Monday.com columns in a later step, so note the field names from your first test run (Deputy commonly exposes Employee, DateStart, DateEnd, and Status).

Step 3: Loop over each leave request

Add a Loop node set to ForEach and point it at the list returned by Deputy, for example {{ leave.result }} (use the array field your test run reveals). Everything you place inside the loop body runs once per leave request, with the current record available as the loop item, for example {{ item }}.

Working one request at a time keeps the Monday.com writes simple and lets you build one item per leave request without juggling arrays in the create step.

Step 4: Skip requests you have already pushed

Inside the loop, add a Connector node in Direct mode using the Monday.com connector and the list-items tool against your board, then add a Condition node to check whether the current Deputy leave ID already appears in the reserved column. If it does, route the true branch to the end of the loop iteration so nothing is created; if it does not, continue to the create step on the false branch.

This guard is what makes re-runs safe. Because Step 2 re-reads the full Deputy leave list every run, without this check the same request would be added to Monday.com again on the next schedule tick. If you prefer a lighter-weight approach, you can instead narrow Step 2 to recent requests and accept occasional duplicates, but the ID check is the reliable option.

Step 5: Create the Monday.com item

Still inside the loop, on the false branch, add a Connector node in Direct mode using the Monday.com connector and the create-item tool. Set these fields:

boardId - your leave-management board ID.
name - a readable item title, for example {{ item.Employee }} leave {{ item.DateStart }}.
groupId - optional, the group on the board where new requests should land (for example a "Pending" group).
columnValues - a structured object keyed by column ID that carries the leave details into your board columns.

A typical columnValues object maps the Deputy fields plus the leave ID you use for deduplication:

{
  "date_col_id": { "date": "{{ item.DateStart }}" },
  "end_date_col_id": { "date": "{{ item.DateEnd }}" },
  "status_col_id": { "label": "{{ item.Status }}" },
  "leave_id_col_id": "{{ item.Id }}",
  "synced_col_id": "{{ scheduledAt }}"
}

Replace each key with the real column ID from your board. The leave_id_col_id entry is the value the Step 4 Condition checks against. If you need to enrich the item with anything Deputy does not return directly (such as the employee's display name), add a Deputy get-employee Direct-mode node earlier in the loop and reference its output.

Step 6: Add a Monday update and notify (optional)

To leave a note on the new row, add a Connector node in Direct mode with the Monday.com create-update tool, passing the new item's ID from the create step's output and a short message such as Imported from Deputy on {{ scheduledAt }}. If you also want a heads-up in email, add a Send Email node at the end of the loop; it sends from Spojit's built-in mail service with templated Recipients, Subject, and Body fields, so you can message the approver that a new request is on the board.

Tips

Match your cron frequency to how quickly your team needs to see requests. Polling every minute rarely helps and uses more runs than necessary; every 10 to 15 minutes during work hours is usually plenty.
Read your column IDs once with the Monday.com get-board tool and paste them into your columnValues object. Column IDs are stable even when you rename a column's display label.
Use the Schedule trigger's {{ scheduledAt }} as a "last synced" stamp on each item so reviewers can see when the row arrived.
If you build interactively, ask Miraxa, the intelligent layer across your automation, something specific like "Add a Loop ForEach over {{ leave.result }} and inside it a Direct-mode Monday.com create-item node," then fine-tune the fields in the properties panel.

Common Pitfalls

Duplicate items on every run. The list-leave tool returns the full current list, not just new requests. Without the Step 4 ID check, each schedule tick re-creates the same items. Always store the Deputy leave ID in a column and compare against it.
Date format mismatches. Monday.com date columns expect a specific structure (a date key with a YYYY-MM-DD value). If dates do not appear, reshape Deputy's date strings with a Transform node before the create step.
Timezone drift. The cron expression runs in the IANA timezone you set on the trigger, not the viewer's local time. Confirm the zone matches your team so "every weekday at 9am" means what you expect.
Status label values. Monday.com status columns only accept labels that already exist on the column. If a Deputy status has no matching label, the column write is ignored; pre-create the labels or map the values in a Transform node.

Testing

Before relying on the schedule, validate on a small scope. Temporarily replace the Schedule trigger with a Manual trigger (or keep the schedule and use the Run button) and execute once. Point the workflow at a test board, or filter Step 2 down to a single known leave request, and confirm exactly one item appears with the right dates and the leave ID stored in your dedup column. Run it a second time and verify the Condition node skips the already-imported request so no duplicate is created. Once a clean run and a clean re-run both behave, switch back to the Schedule trigger and enable the workflow.