# 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.

```yaml
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](/en/docs/automation-flow-control) — 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.

```yaml
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`.                           |

:::callout
**`respectReadPermissions` is opt-_out_, not opt-in.** It defaults to `true`, honouring the table's `read.when` predicate against the comment's author. Set it to `false` deliberately — and only when the automation must fire for every comment regardless of who wrote it.
:::

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](/en/docs/automation-triggers) — the nine trigger types at a glance.
- [Flow Control](/en/docs/automation-flow-control) — the condition-group model `condition` uses.
- [Record Actions](/en/docs/automation-record-actions) — writing rows back from an automation.
- [Record History](/en/docs/record-history) — the revision trail behind `previousRecord`.
- [Table Permissions](/en/docs/table-permissions) — the `read.when` predicate `respectReadPermissions` honours.