English
Table row changed or date reached
Starts the workflow when a row of a Table is added or changed, or when the date of a row is reached (“one month before the due date”). The row lands in data.table, with no triggering email.
The Table row changed or date reached trigger watches a Table of the instance and starts one run per row concerned. Three ways to start, chosen in "Start when":
- A row is added or changed: a case record changes, the consultant is told;
- A row is added: new rows only;
- The date of a row is reached: the value of a date column, shifted by a delay — "one month before the lease ends", "on the signing day", "ten days after the keys are handed over".
There is no connection to choose: the Table belongs to the instance. The run has no triggering email; Send still works when you choose the sending mailbox on the node.
At a glance
- Type:
trigger.table· version 1 - Category: Triggers
- Kind: Trigger — starts a run
- Effect: No external effect (
none) — nothing is written outside Loop & Roll; safe to replay - Needs a carrier email: No
- Connection: None
- Outputs:
main
Parameters
table
Table — Picked from the list, or by its short identifier (its “slug”), which may come from a template.
- Type: Remote resource (
resourceLocator) - Required: Yes
- Ways to choose: pick from a list, type an ID (
table)
event
Start when
- Type: One choice (
options) - Required: Yes
- Default:
changed - Options:
changed— A row is added or changedcreated— A row is addeddate— The date of a row is reached: The value of a date column, shifted by a delay: “one month before the due date”.
dateColumn
Date column — The machine key of the column (for example due_date). A row without a date is skipped.
- Type: Text (
string) - Required: No
- Default:
""(empty) - 60 characters at most
- Shown when:
eventisdate - Expressions:
{{ }}not accepted
offsetAmount
Delay — 0: on the day itself.
- Type: Number (
number) - Required: No
- Default:
0 - Whole number, from 0 to 730
- Shown when:
eventisdate
offsetUnit
Delay unit
- Type: One choice (
options) - Required: No
- Default:
days - Options:
days— daysweeks— weeksmonths— months
- Shown when:
eventisdate
offsetDirection
Before or after the date
- Type: One choice (
options) - Required: No
- Default:
before - Options:
before— before the dateafter— after the date
- Shown when:
eventisdate
everyMinutes
Check every (minutes) — A check reads the instance’s Table: it costs no outside call.
- Type: Number (
number) - Required: No
- Default:
15 - Whole number, from 5 to 1440
- Shown under “Advanced” in the editor
Outputs
main— Taken once per row found during a check: each row starts its own run.
Data produced
What this node adds to the run data, and how to read it in an expression. <step> stands for the step key: the node name turned into an identifier (see Data and expressions).
{{ data.table.row.<column> }}—object. The cells of the row, by column machine key ({{ data.table.row.tenant }}).{{ data.table.rowId }}—string. The row identifier.{{ data.table.event }}—string. What started the trigger:changed(added or changed),created(added) ordate(date reached).{{ data.table.table }}—string. The table, as chosen on the node (its short identifier or its identifier).{{ data.table.updatedAt }}—string. When the row was last changed (ISO 8601).createdAtholds its creation.{{ data.table.date }}—string. Date reached only: the value of the date column (2026-06-04).{{ data.table.fireDay }}—string. Date reached only: the day the trigger fired, the date shifted by the delay (2026-05-04for “one month before June 4”).
Example
A "Leases" table has a date column end_date and a column tenant_email. To write to the tenant one month before the lease ends:
text
table leases
event date
dateColumn end_date
offsetAmount 1
offsetUnit months
offsetDirection beforeOn May 4, each lease ending on June 4 starts a run. A Send node writes to {{ data.table.row.tenant_email }} and quotes {{ data.table.date | date_en:"MMMM d, yyyy" }}.
Tips
- Starting point. On publication, the trigger starts "from now": rows already changed are not replayed, and for a date reached, the dates reached from the publication day on fire. Republishing keeps the position.
- The day of a date reached is the UTC day: a date reached fires at the first check after midnight UTC. An outage of several days loses nothing: the next check catches up every missed day.
- No duplicate. A run is identified by the row and its change (or its date): the same change, the same due date never start two runs. A due date moved to another day fires again on the new day.
- A row without a date is never concerned by a date reached. A date and time column works too: only its day counts.
- Rhythm. Between 5 and 1,440 minutes, 15 by default (advanced setting); the instance may impose a floor (
INTEGRATION_POLL_MIN_MINUTES). A check reads the instance's Table: it costs no outside call. - Volume. A check brings back at most 200 rows. The rest waits for the next check.
- A row written by the workflow itself is a changed row: a workflow started by "added or changed" that writes back to the same table would restart on its own write. Prefer "added", or another table.
- Deletions are not detected.
- Testing. Testing from this trigger really reads the table: the most recently changed row (or the dates reached today); the test never moves the position (see Test runs).