Déclencheurs d'enregistrement et de commentaire

Les deux déclencheurs qui naissent de l'activité à l'intérieur de votre application : une ligne qui change, et quelqu'un qui parle d'une ligne.

Déclencheur d'enregistrement

Se déclenche lorsque des enregistrements changent dans une table surveillée.

app.yaml

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

Propriété	Description
`table`	Nom de la table à surveiller. Obligatoire, non vide.
`events`	Tableau de `create` / `update` / `delete`. Obligatoire, au moins une entrée.
`watchFields`	Sur `update`, ne se déclenche que si l'un de ces champs change. Au moins une entrée si présent.
`condition`	Un groupe de conditions — ne se déclenche que si la ligne correspond.

watchFields et condition répondent à deux questions différentes. watchFields demande ce qui a changé ; condition demande à quoi ressemble la ligne désormais. L'exemple ci-dessus ne se déclenche que si status a été touché et que le statut résultant est paid : une commande passée de pending à paid déclenche, une commande dont l'adresse de livraison est corrigée non.

Contexte de l'enregistrement

La ligne est à {{trigger.data.record.*}} (également accessible via {{trigger.record.*}}). Elle n'est pas aplatie : {{trigger.data.status}} ne se résout donc pas. Deux autres chemins sont disponibles :

Chemin	Disponible sur	Contient
`{{trigger.data.record.*}}`	tous les événements	La ligne après le changement.
`{{trigger.data.previousRecord.*}}`	`update` seulement	La ligne avant le changement.
`{{trigger.data.records}}`	écritures par lot	L'ensemble des lignes affectées.

previousRecord est ce qui rend « notifier quand le statut quitte draft » exprimable sans conserver d'état entre deux exécutions.

Déclencheur de commentaire

Se déclenche lorsqu'un commentaire est créé sur un enregistrement d'une table où les commentaires sont activés.

app.yaml

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

Propriété	Description
`table`	Nom de la table avec commentaires activés. Obligatoire, non vide.
`when`	`approved` (modérés approuvés uniquement), `created` (tout nouveau commentaire) ou `any`. Par défaut `created`.
`filter`	`{ topLevelOnly, repliesOnly, mentionsOnly }` — `topLevelOnly` et `repliesOnly` s'excluent mutuellement.
`respectReadPermissions`	Ne se déclenche que si l'auteur du commentaire peut lire l'enregistrement. Par défaut `true`.

respectReadPermissions est actif par défaut, pas opt-in. Il vaut true et honore le prédicat read.when de la table contre l'auteur du commentaire. Passez-le à false délibérément — et uniquement si l'automatisation doit se déclencher pour chaque commentaire, quel qu'en soit l'auteur.

Choisissez when selon ce que fait l'automatisation. approved convient à tout ce qui est visible des utilisateurs, car un commentaire modéré ne devrait pas alerter un canal avant qu'un humain ne l'ait validé. created convient aux notifications internes qui veulent le commentaire dès son arrivée.

Contexte du commentaire

Un déclencheur de commentaire remet à l'automatisation le commentaire, l'enregistrement auquel il est rattaché et deux audiences déjà constituées — de quoi notifier un fil sans la moindre requête supplémentaire.

Chemin	Type	Contenu
`$trigger.comment.id`	UUID	La ligne du commentaire.
`$trigger.comment.body`	string	Le corps du commentaire (texte enrichi).
`$trigger.comment.author.{id,email,name}`	string	Son auteur.
`$trigger.comment.parentCommentId`	UUID \| null	`null` pour un commentaire racine ; l'identifiant du parent pour une réponse.
`$trigger.record.*`	object	L'enregistrement sur lequel le commentaire a été posté.
`$trigger.threadParticipants`	UUID[]	Tous ceux qui ont écrit dans le fil, hors nouvel auteur.
`$trigger.mentions`	UUID[]	Les utilisateurs nommés dans le balisage `@` du commentaire.
`$trigger.mentionedEmails`	string[]	Les adresses e-mail de ces mêmes utilisateurs, hors auteur du commentaire lui-même.

mentions contient des identifiants ; mentionedEmails contient des adresses. Seule la seconde est un destinataire exploitable. to: '{{trigger.mentions}}' produit une liste d'identifiants séparés par des virgules et l'envoi échoue faute d'adresse — utilisez {{trigger.mentionedEmails}} à la place.

app.yaml

- name: notifyMentioned
  type: email
  operator: send
  props:
    to: '{{trigger.mentionedEmails}}'
    subject: 'You were mentioned on {{trigger.record.title}}'
    body: '{{trigger.comment.author.name}} wrote: {{trigger.comment.body}}'

mentionedEmails écarte l'auteur du commentaire même s'il se mentionne lui-même : personne ne reçoit de notification pour son propre commentaire. Les mentions répétées d'une même personne se réduisent à une seule adresse, et une mention dont l'utilisateur n'existe plus est ignorée plutôt que de faire échouer l'exécution — une notification partiellement délivrée vaut mieux qu'un point de terminaison de commentaire qui avale son automatisation. Associez-le à filter: { mentionsOnly: true } pour que l'automatisation ne s'exécute que lorsqu'il y a quelqu'un à notifier.

Pages connexes

Présentation des déclencheurs — les neuf types en un coup d'œil.
Contrôle de flux — le modèle de groupe de conditions employé par condition.
Actions sur les enregistrements — réécrire des lignes depuis une automatisation.
Historique des enregistrements — la piste de révisions derrière previousRecord.
Permissions de table — le prédicat read.when honoré par respectReadPermissions.

Dernière mise à jour 1 septembre 2026

← PrécédentVariables d'environnement Suivant →Webhook et cron

Modifier cette page Signaler un problème

Cette documentation a été rédigée avec de l'IA : des erreurs ou du contenu obsolète sont donc possibles. Sovrium est en bêta. Les contributions et corrections sont les bienvenues.