Skip to content

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
The ports of “Table row changed or date reached”: what comes in on the left, what goes out on the rightIt starts runs: no input. Outputs: main.Table row changed or datereachedtrigger.tableEventmain
The ports of “Table row changed or date reached”: what comes in on the left, what goes out on the right

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 changed
    • created — A row is added
    • date — 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: event is date
  • 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: event is date

offsetUnit ​

Delay unit

  • Type: One choice (options)
  • Required: No
  • Default: days
  • Options:
    • days — days
    • weeks — weeks
    • months — months
  • Shown when: event is date

offsetDirection ​

Before or after the date

  • Type: One choice (options)
  • Required: No
  • Default: before
  • Options:
    • before — before the date
    • after — after the date
  • Shown when: event is date

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) or date (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). createdAt holds 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-04 for “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  before

On 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).

Loop & Roll — the workflow builder for email.