Mankomail

Appelé par un workflow ​

Ce workflow ne s’abonne à aucun mail : il s’exécute quand un autre l’appelle. L’entrée arrive dans data.input.

Le déclencheur Appelé par un workflow fait d’un workflow une brique réutilisable. Il ne s’abonne à rien de lui-même : le workflow ne s’exécute que lorsqu’un autre workflow atteint un nœud Appeler un workflow qui le vise. Écrivez une routine une fois (un accusé de réception, une procédure de classement), publiez-la, et appelez-la depuis tous les workflows qui en ont besoin.

L’exécution appelée reçoit deux choses :

  • data.input : tout ce que l’appelant avait dans ses données de travail au moment de l’appel ;
  • le mail porteur de l’appelant, s’il en a un. Les nœuds qui agissent sur le mail déclencheur peuvent donc servir dans un workflow appelé, à condition que chaque appelant ait un mail ; si l’appelant est parti d’une planification ou d’un webhook, l’exécution appelée n’a pas de mail non plus, et ces nœuds échouent.

Ce que produit le workflow appelé revient à l’appelant quand l’appel attend la fin : voir Appeler un workflow.

En bref ​

  • Type : trigger.called · version 1
  • Catégorie : Déclencheurs
  • Nature : Déclencheur — lance une exécution
  • Effet : Sans effet externe (none) — rien n’est écrit hors de Mankomail ; rejouable sans risque
  • Exige un mail porteur : Non
  • Connexion : Aucune
  • Sorties : main

Paramètres ​

Ce nœud n’a aucun paramètre.

Sorties ​

  • main — Emprunté par chaque exécution lancée par un nœud Appeler un workflow.

Données produites ​

Ce que ce nœud ajoute aux données de l’exécution, et comment le lire dans une expression. <step> désigne la clé de l’étape : le nom du nœud ramené à un identifiant (voir Données et expressions).

  • {{ data.input }} — object. Les données de travail de l’exécution appelante au moment de l’appel : ses données de déclenchement et les sorties des étapes déjà terminées, sous leurs propres clés.
  • {{ data.input.<step>.<field> }} — string. La sortie d’une étape de l’appelant, par exemple {{ data.input.extraire.fields.montant }}. Les données de déclenchement de l’appelant y figurent aussi : {{ data.input.webhook.… }}, {{ data.input.schedule.plannedFor }}.
  • {{ email.subject }} — string. Le mail porteur de l’appelant, hérité tel quel (tous les champs email.…). Vide quand l’appelant n’en a pas.

Example ​

Un workflow « Accusé de réception » commence par Appelé par un workflow, suivi d’un nœud Envoyer qui répond à {{ email.from.email }} avec la référence extraite par l’appelant : Votre demande {{ data.input.extraire.fields.reference }} a bien été reçue.

Trois workflows (factures, réclamations, devis) se terminent chacun par un nœud Appeler un workflow dont workflowId désigne « Accusé de réception ». Chaque appel crée une exécution d’« Accusé de réception » sur son port main, avec les données de l’appelant sous data.input et son mail sous email.

Tips ​

  • Le workflow appelé doit être publié et porter un déclencheur Appelé par un workflow actif ; sinon l’appel échoue avec une erreur définitive. Seule la version publiée est appelée.
  • Sur un appel, seules les branches qui partent de ce déclencheur s’exécutent. Un workflow qui porte aussi un déclencheur Mail reçu reste appelable : sur un appel, ses branches « mail » ne tournent pas.
  • Un workflow porte au plus un déclencheur Appelé par un workflow.
  • Seuls vos propres workflows peuvent être appelés. Les chaînes sont limitées à trois niveaux sous la première exécution (A appelle B, qui appelle C, qui appelle D), et un cycle (A appelle B, qui appelle A) est refusé.
  • data.input est une photographie prise au moment de l’appel : les étapes ultérieures de l’appelant n’y figurent pas.
  • Une exécution appelée hérite du mode de son appelant : un essai reste un essai dans le workflow appelé, donc rien n’y est envoyé.
  • Pour tester le workflow appelé seul dans l’éditeur, saisissez un objet JSON : il arrive sous data.input, comme un vrai appel (voir Essais).