Due Time trigger
Fire relative to a date already on a record — fifteen minutes before a task is due, or a day after. How it differs from a schedule and from a delay.
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
| 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.
| 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:
taskDefaults totask.
date_field
- What it holds
- Datetime column to evaluate against One of:
due_dateDefaults todue_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_dateDefaults tobefore_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 · daysDefaults tominutes.
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_dateand 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
filtersentry 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.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read