Record Changed
trigger.airtable_record
TriggerFiles & storageconnection requiredruns in-engine
Registers an Airtable webhook at publish, then fetches the change log each time Airtable pings. One run per changed record: {change_type, record_id, fields, previous_fields}.
Start a run when a record is created, updated or deleted in a table.
Connection
- Required
- Yes — the node will not save without one
- Auth type
- Bearer token
- Providers
- Airtable
- Secret shape
- the Airtable personal access token
- Resolved by
- config.connection_id, else node.connection_id
- Note
- The token needs the webhook:manage scope as well as data read access to the base — webhook:manage creates the subscription and reads its change log. Publishing also needs MANTLE_APP_PUBLIC_BASE_URL set: it is the address Airtable calls back on.
Configuration
4 fields, 2 required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.
| Field | Type | Required | Default | Constraints | Example |
|---|---|---|---|---|---|
base_id Base id (app…). It is the first path segment of any Airtable URL. | string | Yes | — | matches ^app[A-Za-z0-9]+$ | appXXXXXXXXXXXXXX |
table_id Table id (tbl…), not the table name — Airtable filters record changes by id, and a name matches nothing. | string | Yes | — | matches ^tbl[A-Za-z0-9]+$ | tblXXXXXXXXXXXXXX |
change_types Which changes fire the workflow. | array | No | ["add","update","remove"] | ≥ 1 characters; array of string | — |
watch_fields Optional: only fire when these columns change, by field id (fld…). Leave empty to watch the whole record. | array | No | — | array of string | — |
Example configuration
Every value below is the contract’s own example or default — nothing invented.
{
"base_id": "appXXXXXXXXXXXXXX",
"change_types": [
"add",
"update",
"remove"
],
"table_id": "tblXXXXXXXXXXXXXX"
}Output
One shape.
record change
One record change, flat. `fields` and `previous_fields` are keyed by Airtable field id (fld…), which is what the change log carries.
| Field | Type | Example |
|---|---|---|
base_id The base the change happened in. | string | appXXXXXXXXXXXXXX |
table_id The table the record belongs to. | string | tblXXXXXXXXXXXXXX |
change_type add, update or remove — one record changed, one run. | string | update |
record_id The Airtable record id. | string | recXXXXXXXXXXXXXX |
fields Cell values after the change, keyed by field id. On an update Airtable sends only the cells that changed, not the whole record; on an add it is the new record. Empty for a removed record. | object | — |
previous_fields The same cells as `fields`, as they were before the change — populated on updates, empty on adds and removes. | object | — |
timestamp When Airtable recorded the transaction (ISO 8601). | string | — |
transaction_number Airtable's per-base transaction number. Part of the idempotency key and a reliable ordering for changes in one base. | number | — |
source What made the change: client, publicApi, automation, formSubmission, sync… | string | client |
cursor Position of this transaction in the webhook's payload log. | number | — |
payload Airtable's own change object for this record — `current`/`previous`/`unchanged` for an update, the created record for an add. | object | — |
{
"base_id": "appXXXXXXXXXXXXXX",
"change_type": "update",
"cursor": 0,
"fields": {},
"payload": {},
"previous_fields": {},
"record_id": "recXXXXXXXXXXXXXX",
"source": "client",
"table_id": "tblXXXXXXXXXXXXXX",
"timestamp": "",
"transaction_number": 0
}Notes
- Only changes made after the workflow is published fire it — the webhook's change log starts when the subscription is created, so nothing is replayed.
- One run per changed record, idempotent on Airtable's own transaction number, so a re-read of the change log cannot start a second run.
- Deliveries are verified against Airtable's MAC secret before any run starts; an unsigned or mis-signed POST is refused with 401.
- The subscription expires after 7 days and is refreshed automatically while the workflow is published; it is deleted at Airtable when the workflow is unpublished, disabled or archived.
See Record Changed run in a workflow.
In a technical demo we add the Airtable connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.