Module · Something changed in the CRM

Due Time trigger

Lesson 3 of 10 · 3 min

Some work is anchored to a date that already exists in your data. A task is due at four o'clock; somebody should be reminded at quarter to. The date is not the same for every record, and nothing is changing when the moment arrives.

The Due Time Trigger watches a date field and fires at an offset from it — before or after.

Three ways to be time-based, and they are different

Getting this wrong is the most common time-related mistake in the builder.

	Clock starts	Fires
Due Time trigger	A date stored on a record.	Per record, at its own time.
Scheduler trigger	A calendar.	Once, for everyone, at a fixed time.
Delay node	Something that just happened.	Inside a run that is already going.

Due Time trigger

Clock starts: A date stored on a record.
Fires: Per record, at its own time.

Scheduler trigger

Clock starts: A calendar.
Fires: Once, for everyone, at a fixed time.

Delay node

Clock starts: Something that just happened.
Fires: Inside a run that is already going.

“Remind me fifteen minutes before each task is due” is this trigger. “Every morning, list today's tasks” is a scheduler. “Wait three days after they signed up” is a delay. The tell is whether the moment is stored on the record.

A worked example

Fifteen minutes before due

Click the trigger to see how the offset is expressed.

All seven fields.

Field	What it holds
`entity_type`	Which CRM entity to watch One of: `task` Defaults to `task`.
`date_field`	Datetime column to evaluate against One of: `due_date` Defaults to `due_date`.
`trigger_kind`	before_date = N units before the field's value; after_date = N units after One of: `before_date · after_date` Defaults to `before_date`.
`offset_value`	How many units before/after the date to fire Defaults to `15`.
`offset_unit`	— One of: `minutes · hours · days` Defaults to `minutes`.
`filters`	Optional filters to narrow which rows fire the trigger
`enabled`	— Defaults to `true`.

entity_type

What it holds: Which CRM entity to watch One of: task Defaults to task.

date_field

What it holds: Datetime column to evaluate against One of: due_date Defaults to due_date.

trigger_kind

What it holds: before_date = N units before the field's value; after_date = N units after One of: before_date · after_date Defaults to before_date.

offset_value

What it holds: How many units before/after the date to fire Defaults to 15.

offset_unit

What it holds: — One of: minutes · hours · days Defaults to minutes.

filters

What it holds: Optional filters to narrow which rows fire the trigger

enabled

What it holds: — Defaults to true.

The offset is three fields rather than one: trigger_kind for the direction, then a value and a unit. before_date with 15 minutes is a nudge; after_date with 1 day is a chase for something that did not happen.

What it can watch, today

Tasks and due dates only, for now. Both enums are single-valued in the current schema — entity_type accepts task, and date_field accepts due_date. So “three days before a deal's expected close” is not this trigger yet. Verified 2026-08-01; the shape of the config suggests it is built to widen, so re-check before assuming.

Until it does, the pattern for other dates is a Scheduler trigger that queries for records whose date falls in the window you care about, then loops. More moving parts, and it works on any field.

Narrowing which records

filters limits which tasks count — by owner, by type, by status. Worth setting: without it, every task in the organisation with a due date will fire this workflow, including ones created by other automations, which is rarely what anyone means.

Reading the record

This trigger declares no output fields. Unlike the Database Change Trigger, which hands you the whole row, this one does not publish a documented set of outputs. Do not guess at {{duetimetrigger_1.task.title}} — add a CRM Manager get as the first step and read the task from there. Verified against the live schema; if that changes, the validator will tell you, because it checks references against a node's real outputs.

Try it

Add a Due Time Trigger with before_date, 5 minutes, and have it write a note.
Create a task due in about ten minutes, and wait. This is the one trigger you cannot test instantly, which is itself worth experiencing.
Switch to after_date and think about what you would want to happen a day after a task was due and still open — that is the more useful half of this node.
Add a filters entry so only tasks of one type qualify.

Next: the User Message Trigger, and the second family — a person contacting you rather than your data changing.