Record & Comment Triggers

The two triggers that fire from activity inside your app: a row changing, and someone talking about a row.

Record Trigger

Fires when records change in a watched table.

trigger:
  type: record
  table: orders
  events: [create, update]
  watchFields: [status]
  condition:
    conditions:
      - field: '{{trigger.data.record.status}}'
        operator: equals
        value: paid

Property	Description
table	Name of the table to watch. Required, non-empty.
events	Array of create / update / delete. Required, at least one entry.
watchFields	On update, only fire when one of these fields changes. At least one entry when present.
condition	A condition group — only fire when the row matches the predicate.

watchFields and condition answer different questions. watchFields asks what changed; condition asks what the row now looks like. The example above fires only when status was touched and the resulting status is paid — an order edited from pending to paid fires, an order whose shipping address is corrected does not.

Record context

The row is at {{trigger.data.record.*}} (also reachable as {{trigger.record.*}}). It is not flattened, so {{trigger.data.status}} does not resolve. Two further paths are available:

Path	Available on	Contains
{{trigger.data.record.*}}	all events	The row after the change.
{{trigger.data.previousRecord.*}}	update only	The row before the change.
{{trigger.data.records}}	batch writes	The full set of affected rows.

previousRecord is what makes "notify when the status left draft" expressible without storing state between runs.

Comment Trigger

Fires when a comment is created on a record in a comments-enabled table.

trigger:
  type: comment
  table: tickets
  when: created
  filter: { mentionsOnly: true }

Property	Description
table	Name of the table with comments enabled. Required, non-empty.
when	approved (moderated-approved only), created (any new comment), or any. Defaults to created.
filter	{ topLevelOnly, repliesOnly, mentionsOnly } — topLevelOnly and repliesOnly are mutually exclusive.
respectReadPermissions	Only fire when the comment author can read the record. Defaults to true.

Pick when by what the automation does. approved is right for anything user-visible, since a moderated comment should not page a channel before a human clears it. created is right for internal notifications that want the comment the moment it lands.

Comment triggers expose $trigger.comment.*, $trigger.record.*, $trigger.threadParticipants and $trigger.mentions — enough to notify a thread's participants without a lookup.

Related Pages

• Triggers Overview — the nine trigger types at a glance.
• Flow Control — the condition-group model condition uses.
• Record Actions — writing rows back from an automation.
• Record History — the revision trail behind previousRecord.
• Table Permissions — the read.when predicate respectReadPermissions honours.