Déclencheurs et conditions

Un déclencheur est le nœud qui lance un workflow. Il se place à gauche du canvas, n’a pas d’entrée et ne s’exécute jamais comme une étape : quand il tire, il crée une exécution et la confie aux nœuds branchés après lui. Cette page liste tous les déclencheurs, ce qui fait tirer chacun, ce qu’il apporte à l’exécution, et la façon d’écrire les conditions du déclencheur mail.

Le déroulement du reste du graphe est expliqué dans Workflows.

Les déclencheurs en un coup d’œil

Type	Nom dans l’éditeur	Tire quand	Mail porteur	Données apportées
trigger.email	Mail reçu	un nouveau mail qui satisfait les conditions arrive dans l’une de vos boîtes	oui	le mail, sous email
trigger.webhook	Webhook reçu	un POST HTTP atteint l’URL du workflow	non	le corps JSON, sous data.webhook
trigger.called	Appelé par un workflow	un autre workflow l’exécute avec « Appeler un workflow »	celui de l’appelant, s’il en a un	les données de l’appelant, sous data.input
trigger.schedule	Planification	l’horloge atteint l’occurrence suivante	non	data.schedule
trigger.manual	Lancement manuel	vous le lancez sur un mail	oui	le mail, sous email
trigger.airtable	Ligne Airtable modifiée	une vérification trouve des lignes nouvelles ou modifiées	non	data.airtable
trigger.notion_changes	Entrée Notion modifiée	une vérification trouve des entrées nouvelles ou modifiées	non	data.notion
trigger.notion	Notion — événement	Notion envoie un événement à l’URL du workflow	non	data.notion
trigger.mynotary	MyNotary — événement	MyNotary envoie un événement à l’URL du workflow	non	data.mynotary
trigger.yousign	Yousign — événement	Yousign envoie un événement signé à l’URL du workflow	non	data.yousign

Un déclencheur ne tire qu’une fois le workflow publié, sauf trigger.manual, qui ne tire jamais tout seul (c’est vous qui lancez). Mettre un workflow en pause arrête les déclencheurs mail, planifiés et par sondage sans la mettre hors ligne.

Plusieurs déclencheurs dans un workflow

Un workflow peut porter plusieurs déclencheurs. Chaque exécution retient le déclencheur qui l’a lancée, et seules les branches branchées après ce déclencheur s’exécutent. Un workflow doté d’un déclencheur mail et d’un déclencheur webhook n’exécute que ses branches « webhook » quand un appel arrive.

• trigger.email se répète autant que vous voulez : chaque exemplaire est un jeu de conditions de plus. Quand un même mail satisfait deux déclencheurs mail du même workflow, le workflow ne s’exécute quand même qu’une fois sur ce mail, par le déclencheur dont l’identifiant de nœud vient en premier dans l’ordre alphabétique.
• trigger.webhook, trigger.called, trigger.mynotary, trigger.notion et trigger.yousign ne peuvent figurer qu’une fois par workflow (duplicate_trigger à la publication). L’URL et la capacité d’être appelé appartiennent au workflow, pas à un nœud.
• Un workflow n’a qu’une URL. Utilisez un seul déclencheur à URL par workflow (trigger.webhook ou un déclencheur d’événements d’intégration), pas plusieurs de types différents.
• Un déclencheur désactivé ne tire pas. Un workflow dont tous les déclencheurs sont désactivés se publie quand même, avec l’avertissement all_triggers_disabled.

Le mail porteur

Certains déclencheurs apportent un mail à l’exécution, d’autres non. C’est ce qui décide des nœuds utilisables.

Ce qu’apportent les déclencheurs	Déclencheurs	Conséquence pour les nœuds qui agissent sur le mail
Garanti — chaque exécution a un mail	uniquement trigger.email et/ou trigger.manual	autorisés
Hérité — le mail du workflow appelant, s’il en a un	trigger.called, éventuellement avec des déclencheurs mail ou manuels, et aucun des déclencheurs ci-dessous	autorisés, avec l’avertissement carrier_email_inherited : ils fonctionnent quand l’appelant a été lancé par un mail, et échouent quand il l’a été par une planification ou un webhook
Absent — au moins un déclencheur lance des exécutions sans mail	l’un de trigger.webhook, trigger.schedule, trigger.airtable, trigger.notion_changes, trigger.notion, trigger.mynotary, trigger.yousign	refusés à la publication avec carrier_email_required

Tous les déclencheurs comptent, désactivés compris : ajouter une planification à un workflow mail, même désactivée, rend le mail absent pour tout le workflow.

Ce que veut dire « agir sur le mail » :

• Les nœuds qui exigent le mail : mail.move (Classer) et mail.flag (Marquer). Sans mail, ils n’ont rien sur quoi agir.
• Les réglages qui exigent le mail : « Répondre dans le fil » de mail.compose (Rédiger) et de ai.compose (Rédiger (IA)) — décoché par défaut quand le mail est absent ; « Répondre dans le fil » (reply) de mail.send (Envoyer) — choisissez plutôt « Nouveau fil » ou la valeur par défaut ; et le réveil anticipé « Une réponse arrive dans le fil » de flow.wait (Attendre).

Un nœud désactivé n’est jamais vérifié : il ne s’exécute pas. Pour travailler sur un mail depuis un workflow webhook ou planifié, retrouvez-le à partir des données (par exemple par une référence rangée dans une table) plutôt que de compter sur un mail porteur.

Mail reçu (trigger.email)

trigger.email lance le workflow quand un nouveau mail qui satisfait ses conditions arrive dans l’une de vos boîtes. Un nouveau workflow démarre avec ce déclencheur déjà en place.

Quelles boîtes. La publication arme le déclencheur sur toutes les boîtes qui vous appartiennent et ne sont pas déconnectées. Une boîte connectée plus tard est armée automatiquement, sans republier. Il n’existe pas de réglage de boîte par déclencheur.

Quels mails peuvent atteindre un déclencheur. Avant toute évaluation des conditions, un mail doit :

• être nouveau : livré par la synchronisation après la connexion de la boîte. L’historique importé à la connexion d’une boîte ne lance jamais de workflow, pas plus qu’un ancien mail qui réapparaît (restauré depuis la corbeille, réétiqueté) ;
• ne pas se trouver dans Envoyés, Spam, Corbeille ou Brouillons ;
• être dans le périmètre : non exclu par les règles de périmètre de l’organisation ou par les vôtres ;
• ne pas être arrêté par un garde-fou : les mails envoyés par Mankomail lui-même (par exemple la réponse d’un workflow qui revient par la synchronisation), les réponses automatiques (absence du bureau et assimilées), les mails de listes de diffusion et de newsletters, et ceux d’adresses no-reply n’atteignent jamais les déclencheurs.

À cause des garde-fous, des conditions comme signals.isMailingList égal à true ou signals.isAutoReply égal à true ne se vérifient jamais en pratique. Les champs de signaux restent utiles pour exclure, par exemple signals.isAutoReply égal à false.

Les mails déjà présents ne sont pas traités. Publier un workflow ne l’applique pas aux mails déjà reçus : seuls les mails qui arrivent ensuite sont examinés. Pour exécuter un workflow publié sur un mail que vous avez déjà, utilisez un lancement manuel.

Une exécution par mail et par version. Un même mail livré deux fois (notification et relève, rejeux) ne lance une version publiée donnée qu’une seule fois.

Quand plusieurs workflows correspondent au même mail, votre politique de déclenchement décide, dans vos réglages de périmètre, sous « Ma politique de déclenchement » :

• « Tous ceux qui correspondent » (défaut) : chaque workflow qui correspond a sa propre exécution ;
• « Le premier qui correspond, et lui seul » : les workflows sont essayés dans l’ordre de priorité et seul le premier qui correspond s’exécute. L’ordre est le « Rang » de l’onglet « Réglages » de chaque workflow, de 0 à 9999, le plus petit d’abord ; les workflows sans rang passent après, dans l’ordre de création.

Le déclencheur affiche aussi un réglage « Si plusieurs workflows correspondent » (multiMatch : inherit, all, priority). La politique réellement appliquée est celle de vos réglages, pour tous les workflows.

Les conditions du déclencheur mail

Les conditions de trigger.email (paramètre conditions) forment un arbre de groupes et de feuilles :

• un groupe s’écrit { "all": [ … ] } (tous les enfants doivent être vrais) ou { "any": [ … ] } (au moins un doit l’être), et les groupes peuvent s’imbriquer ;
• une feuille s’écrit { "field": …, "op": …, "value": …, "caseSensitive": … }.

Aucune condition veut dire que le déclencheur écoute tous les mails qui peuvent l’atteindre.

{
  "all": [
    { "field": "from.domain", "op": "matchesDomain", "value": "client.example" },
    { "field": "attachments.mimeTypes", "op": "contains", "value": "application/pdf" },
    {
      "any": [
        { "field": "subject", "op": "contains", "value": "facture" },
        { "field": "subject", "op": "contains", "value": "invoice" }
      ]
    }
  ]
}

Ce déclencheur tire pour un mail venu de client.example ou de l’un de ses sous-domaines, avec une pièce jointe PDF, dont l’objet contient « facture » ou « invoice », quelle que soit la casse.

Dans l’éditeur, le panneau du déclencheur édite un seul niveau : choisissez « Toutes » ou « Au moins une » sous « Combinaison des conditions », puis ajoutez des conditions (Champ, Opérateur, Valeur). Les groupes imbriqués écrits par l’API sont conservés et signalés comme « groupes imbriqués conservés — non modifiables ici ». « Conditions toutes faites… » insère des conditions courantes, par exemple « A au moins une pièce jointe », « A une pièce jointe PDF » ou « N’est pas une réponse automatique ».

Les champs des conditions

Chaque champ a un type, qui décide des opérateurs permis et du type de value.

Champ	Libellé dans l’éditeur	Type	Contenu
from.email	Expéditeur (adresse)	texte	l’adresse de l’expéditeur
from.name	Expéditeur (nom)	texte	le nom affiché de l’expéditeur
from.domain	Expéditeur (domaine)	texte	le domaine de l’expéditeur, en minuscules, sans point final
to.emails	Destinataires (adresses)	liste	les adresses en À
to.domains	Destinataires (domaines)	liste	les domaines en À
cc.emails	Copie (adresses)	liste	les adresses en Cc
cc.domains	Copie (domaines)	liste	les domaines en Cc
recipients.emails	Tous destinataires (adresses)	liste	À + Cc + Cci — le champ à utiliser pour « adressé à cet alias »
recipients.domains	Tous destinataires (domaines)	liste	les domaines de À + Cc + Cci
replyTo.emails	Répondre à (adresses)	liste	les adresses de Reply-To
subject	Objet	texte	l’objet
bodyText	Corps du message	texte	le corps complet en texte brut
receivedAt	Date de réception	texte	date et heure ISO 8601 en UTC
sentAt	Date d’envoi	texte	date et heure ISO 8601 en UTC, quand le mail en porte une
attachments.count	Nombre de pièces jointes	nombre	le nombre de vraies pièces jointes ; les images intégrées comme les logos de signature ne comptent pas
attachments.filenames	Noms des pièces jointes	liste	les noms de fichiers des vraies pièces jointes
attachments.mimeTypes	Types des pièces jointes	liste	les types MIME des vraies pièces jointes (application/pdf)
folderLabels	Dossiers / libellés	liste	les dossiers IMAP ou libellés Gmail du mail
flags.seen	Lu	oui/non	lu
flags.flagged	Suivi	oui/non	suivi / étoilé
flags.draft	Brouillon	oui/non	brouillon
flags.sent	Envoyé	oui/non	envoyé
signals.isAutoReply	Réponse automatique	oui/non	détecté comme réponse automatique
signals.isNoReply	Adresse no-reply	oui/non	envoyé depuis une adresse no-reply
signals.isMailingList	Liste de diffusion	oui/non	détecté comme mail de liste de diffusion ou d’envoi de masse
signals.isFromSelf	Envoyé par moi	oui/non	envoyé par l’une de vos propres adresses
header:<nom>	—	liste	toutes les valeurs d’un en-tête brut, par exemple header:list-id ou header:x-mailer

header:<nom> est disponible dans le document et par l’API, pas dans la liste de champs de l’éditeur. Le nom de l’en-tête s’écrit en lettres minuscules, chiffres et tirets (header:x-priority, pas header:X-Priority).

Les opérateurs des conditions

Opérateur	Libellé dans l’éditeur	Champs texte	Champs nombre	Champs oui/non	Champs liste
eq	est égal à	✓	✓	✓	✓
neq	est différent de	✓	✓	✓	✓
contains	contient	✓	—	—	✓
startsWith	commence par	✓	—	—	✓
endsWith	finit par	✓	—	—	✓
gt	est supérieur à	✓	✓	—	—
lt	est inférieur à	✓	✓	—	—
exists	est renseigné	✓	✓	✓	✓
matchesDomain	a pour domaine	✓	—	—	✓

Types de valeur. Les champs texte et liste prennent une value texte ; les champs nombre un nombre (0, pas "0") ; les champs oui/non true ou false. matchesDomain prend toujours une valeur texte. exists se passe de valeur (ou prend true) pour vérifier que le champ est renseigné, et prend false pour vérifier qu’il ne l’est pas.

Le comportement de chaque opérateur :

• Les comparaisons de texte ignorent la casse par défaut mais respectent les accents : cafe.fr et café.fr sont différents. Ajoutez "caseSensitive": true à une feuille pour comparer à l’identique. Les différentes écritures Unicode d’un même caractère sont considérées comme égales.
• Sur les champs liste, un opérateur est vrai quand au moins un élément le satisfait (to.domains contient client est vrai si l’un des domaines en À le contient). neq fait exception : il est vrai quand aucun élément n’est égal, si bien qu’une liste vide le satisfait.
• matchesDomain compare des domaines : la valeur est un domaine ou une adresse (seule la partie après @ compte), et le champ satisfait la condition quand son domaine est ce domaine ou l’un de ses sous-domaines. from.email a pour domaine client.example est vrai pour anna@mail.client.example.
• gt et lt sur du texte comparent dans l’ordre alphabétique. Sur receivedAt et sentAt, qui sont des dates ISO en UTC, cela revient à une comparaison chronologique : receivedAt est supérieur à 2026-10-01 est vrai pour tout mail reçu à partir du 1ᵉʳ octobre 2026 (UTC).
• exists est vrai pour un champ texte non vide, une liste qui a au moins un élément, et un champ nombre ou oui/non qui a une valeur.
• Un champ texte que le mail ne porte pas (pas d’expéditeur, pas de sentAt) rend tous les opérateurs faux, sauf exists avec false. Les champs liste sont toujours présents, éventuellement vides.

Les erreurs de conditions

La publication refuse des conditions inévaluables avec l’erreur invalid_trigger_conditions et un problème par feuille fautive, repérée par son chemin dans l’arbre (all[0].any[2]) :

Problème	Signification
unknown_field	le champ ne figure pas dans la liste ci-dessus
op_not_supported	l’opérateur n’est pas permis sur ce type de champ (par exemple contains sur attachments.count)
missing_value	l’opérateur exige une valeur
invalid_value_type	la valeur n’a pas le bon type ("0" au lieu de 0, une valeur non booléenne pour exists)
empty_group	un groupe n’a aucun enfant : un all vide accepterait tous les mails, un any vide aucun

Les conditions sont vérifiées aussi sur les déclencheurs mail désactivés, pour qu’on puisse les réactiver sans surprise.

Exemples de conditions

A au moins une vraie pièce jointe :

{ "all": [ { "field": "attachments.count", "op": "gt", "value": 0 } ] }

Adressé à un alias donné, où qu’il figure (À, Cc ou Cci) :

{ "all": [ { "field": "recipients.emails", "op": "eq", "value": "factures@entreprise.example" } ] }

Venu de l’un de deux clients, et pas une réponse automatique :

{
  "all": [
    { "any": [
      { "field": "from.domain", "op": "matchesDomain", "value": "client-a.example" },
      { "field": "from.domain", "op": "matchesDomain", "value": "client-b.example" }
    ] },
    { "field": "signals.isAutoReply", "op": "eq", "value": false }
  ]
}

Objet qui commence exactement par une référence en majuscules :

{ "all": [ { "field": "subject", "op": "startsWith", "value": "REF-", "caseSensitive": true } ] }

Aucune adresse en copie :

{ "all": [ { "field": "cc.emails", "op": "exists", "value": false } ] }

Le même arbre, avec des champs préfixés email., des champs de données data.<chemin> et l’opérateur supplémentaire isEmpty, sert au nœud Condition (Si) plus loin dans le graphe.

Webhook reçu (trigger.webhook)

trigger.webhook lance le workflow sur un appel HTTP. Il n’a aucun réglage.

L’URL. Chaque workflow qui utilise ce déclencheur a une URL :

<PUBLIC_BASE_URL>/hooks/wf/<jeton>

Le jeton (256 bits aléatoires) est créé à la première publication, ou plus tôt avec « Générer l’URL » dans le panneau du déclencheur. Il n’est affiché qu’une fois : seule une empreinte est conservée, personne ne peut donc le réafficher. Si vous le perdez, ou s’il a fuité, utilisez « Régénérer l’URL » : l’URL précédente cesse aussitôt de fonctionner. Republier conserve la même URL. L’éditeur affiche le chemin qui commence par /hooks/wf/ ; faites-le précéder de l’adresse de votre instance. Par l’API, POST /api/v1/workflows/:id/webhook génère un nouveau jeton et le renvoie une fois.

Le jeton est l’authentification : aucun en-tête ni aucune clé n’est demandé. Traitez l’URL comme un secret.

La requête.

curl -X POST "<PUBLIC_BASE_URL>/hooks/wf/<jeton>" \
  -H "Content-Type: application/json" \
  -d '{"client": {"nom": "Jeanne Martin", "email": "jeanne@example.com"}}'

• Méthode : POST uniquement.
• Corps : du JSON, 256 Ko au plus (262 144 octets). Le corps devient data.webhook : ici {{ data.webhook.client.email }}. Un corps vide donne null. Les en-têtes et la chaîne de requête ne sont pas transmis au workflow.

Les réponses.

Statut	Corps	Quand
202	{ "executionId": "…" }	l’exécution est créée ; elle tourne en arrière-plan
400	erreur	le corps n’est pas du JSON valide
404	{ "code": "not_found", … }	jeton inconnu, ou workflow non publié, archivé, ou sans déclencheur webhook actif — tous répondent de la même façon
413	{ "code": "request.payload_too_large", … }	le corps dépasse 256 Ko
429	vide, avec Retry-After	trop d’appels depuis votre adresse ; réessayez plus tard

Chaque appel crée une nouvelle exécution : deux appels identiques font deux exécutions. L’exécution n’a pas de mail porteur (voir le mail porteur).

Détails : Webhook reçu.

Appelé par un workflow (trigger.called)

trigger.called rend un workflow appelable par d’autres avec le nœud Appeler un workflow. Il n’a aucun réglage, ne s’abonne à aucun mail, et ne tire que lorsqu’on l’appelle.

• Les données de travail de l’appelant arrivent sous {{ data.input }}.
• L’exécution hérite du mail porteur de l’appelant quand celui-ci en a un ; sinon, elle n’en a pas.
• Le workflow doit être publié pour être appelable, et un seul trigger.called est permis par workflow.
• Un workflow peut porter aussi des déclencheurs mail : lorsqu’il est appelé, seules les branches qui suivent trigger.called s’exécutent.

Détails : Appelé par un workflow.

Planification (trigger.schedule)

trigger.schedule lance le workflow à heures régulières, sans mail porteur.

Réglage	Libellé	Valeurs
mode	Rythme	interval — « Toutes les N minutes » (défaut), ou cron — « Expression cron »
everyMinutes	Toutes les (minutes)	nombre entier de 5 à 44 640 (31 jours) ; 60 par défaut
cron	Expression cron	cinq champs : minute, heure, jour du mois, mois, jour de la semaine
timezone	Fuseau horaire	nom IANA comme Europe/Paris ; vide = UTC

Les expressions cron acceptent, dans chaque champ, *, un nombre, un intervalle a-b, une liste x,y,z de ces formes, et un pas /n (*/15, 0/15, 8-18/2). Les mois acceptent JAN à DEC et les jours de la semaine SUN à SAT ; le jour de la semaine va de 0 à 7, 0 et 7 désignant tous deux le dimanche. Les extensions comme ?, L, W et # sont refusées. Une expression qui tirerait plus souvent que toutes les 5 minutes est refusée.

Expression	Signification
0 8 * * 1	tous les lundis à 8 h
0 9 * * 1-5	les jours de semaine à 9 h
*/15 8-18 * * MON-FRI	toutes les 15 minutes de 8 h à 18 h 45, en semaine
30 7 1 * *	le 1ᵉʳ de chaque mois à 7 h 30

L’expression cron est lue dans le fuseau choisi, changements d’heure compris. Le panneau du déclencheur affiche les « Prochaines exécutions » calculées par le serveur. Les intervalles sont alignés sur des instants fixes et non sur l’heure de publication : toutes les 60 minutes tire à l’heure pile (UTC).

Ce que reçoit l’exécution, sous data.schedule : plannedFor (l’heure prévue, ronde comme demandé, en ISO 8601), firedAt (l’heure réelle) et timezone.

Fiabilité. Chaque occurrence crée au plus une exécution. Si le service était arrêté à l’heure prévue, seule la dernière occurrence manquée est rattrapée, en quelques minutes ; les précédentes sont sautées plutôt que tirées en rafale. Un workflow en pause saute ses occurrences.

La publication refuse une planification inutilisable avec invalid_schedule et l’un des motifs : cron_missing, cron_field_count, cron_field_syntax, cron_too_frequent, interval_out_of_range, unknown_timezone.

Détails : Planification.

Lancement manuel (trigger.manual)

trigger.manual signale un workflow destiné à être lancé à la main. Rien ne l’arme : la publication affiche l’avertissement trigger_not_armed, qui rappelle seulement que c’est vous qui lancez.

Un lancement manuel exécute la version publiée pour de bon, sur un mail :

• dans le webmail, ouvrez le mail, choisissez « Lancer un workflow », puis le workflow (« Exécution réelle de la version publiée : les effets partent pour de bon. ») ;
• par l’API, POST /api/v1/workflows/:id/run avec { "messageId": "…" }, et un clientToken facultatif pour qu’une requête répétée ne crée qu’une exécution.

Tout workflow publié peut être lancé ainsi, avec ou sans trigger.manual. Si le workflow porte un trigger.manual actif, seules les branches qui le suivent s’exécutent ; sinon, toutes les branches qui partent d’un déclencheur s’exécutent. Le mail doit appartenir à l’une de vos boîtes. Pour essayer un brouillon sans effet, utilisez plutôt un essai.

Détails : Lancement manuel.

Les déclencheurs d’intégration par sondage

trigger.airtable et trigger.notion_changes demandent au service « quoi de neuf depuis la dernière fois ? » à intervalle régulier, et créent une exécution par élément nouveau ou modifié.

Déclencheur	Surveille	Intervalle (« Vérifier toutes les (minutes) »)	Données
trigger.airtable (Ligne Airtable modifiée)	les lignes d’une table Airtable, éventuellement une vue et une formule supplémentaire ; exige un champ « Date de dernière modification » (ou « Date de création »)	de 5 à 1 440 minutes, 15 par défaut	data.airtable : baseId, tableId, recordId, changedAt, fields
trigger.notion_changes (Entrée Notion modifiée)	les entrées d’une base Notion : créées ou modifiées, nouvelles seulement, ou modifiées seulement	de 5 à 1 440 minutes, 15 par défaut	data.notion

• Point de départ : la première publication commence à surveiller à partir de maintenant. Les lignes ou entrées qui existaient avant ne sont pas rejouées, et republier ne remet jamais la position à zéro.
• Ni perte, ni doublon : chaque élément crée une exécution, même si une vérification est répétée après un incident.
• Un lot borné par vérification : ce qui ne tient pas est repris à la vérification suivante.
• L’instance peut imposer un minimum plus lent (INTEGRATION_POLL_MIN_MINUTES, 5 minutes par défaut) : un déclencheur ne vérifie jamais plus souvent.
• Les erreurs : une erreur temporaire (limite de débit, panne) ne change rien et la vérification suivante retente ; une erreur définitive (connexion révoquée, base supprimée) vous envoie une notification par panne.
• Un workflow en pause saute ses vérifications.

Détails : Ligne Airtable modifiée, Entrée Notion modifiée, et les intégrations Airtable et Notion.

Les déclencheurs d’intégration par webhook

trigger.mynotary, trigger.yousign et trigger.notion reçoivent les événements sur la même URL de workflow que trigger.webhook (<PUBLIC_BASE_URL>/hooks/wf/<jeton>, créée et affichée une seule fois de la même façon). Chacun porte une connexion au service et un réglage « Événements ».

Déclencheur	Événement par défaut	Vérification de l’origine	Doublons
trigger.mynotary (MyNotary — événement)	signature_completed	le jeton d’URL seul (MyNotary ne signe pas)	non dédupliqués : une livraison répétée par MyNotary crée une seconde exécution
trigger.yousign (Yousign — événement)	signature_request.done	signature x-yousign-signature-256 vérifiée avec le secret de la connexion	dédupliqués sur event_id : les rejeux de Yousign ne déclenchent rien
trigger.notion (Notion — événement)	page.properties_updated	signature X-Notion-Signature vérifiée avec le jeton de vérification de la connexion	dédupliqués sur l’identifiant d’événement

• Le filtre d’événements : seuls les événements cochés créent des exécutions. Les autres reçoivent 202 et ne créent rien, pour que l’émetteur ne retente pas. Si rien n’est coché, tous les événements sont acceptés.
• Une signature refusée reçoit le même 404 qu’un jeton inconnu.
• Les abonnements se créent côté service : par l’opération d’API du nœud d’intégration pour MyNotary et Yousign (ou à la main dans Yousign), et à la main dans le portail développeur de Notion pour Notion. Notion peut aussi être surveillé sans aucune configuration avec trigger.notion_changes.
• Le corps arrive sous data.mynotary, data.yousign ou data.notion, tel que le service l’a envoyé. Traitez-le comme une donnée non fiable.

Détails : MyNotary — événement, Yousign — événement, Notion — événement, et les intégrations MyNotary, Yousign et Notion.

Pause et armement

Déclencheur	Armé par la publication	Arrêté par la pause
trigger.email	oui, sur toutes vos boîtes non déconnectées	oui
trigger.schedule	oui, une planification par déclencheur actif	oui
trigger.airtable, trigger.notion_changes	oui, une règle de sondage par déclencheur actif	oui
trigger.webhook, trigger.mynotary, trigger.yousign, trigger.notion	oui, l’URL du workflow répond	non
trigger.called	oui, le workflow devient appelable	non
trigger.manual	non — c’est vous qui lancez	—

Mettre hors ligne ou archiver désarme tous les déclencheurs : l’URL répond 404, planifications et sondages s’arrêtent, et le workflow ne peut plus être appelé.