Skip to content

Approbation ​

Suspend l’exécution jusqu’à ce qu’un humain approuve ou rejette. Demande envoyée par mail, avec un délai.

Le nœud Approbation met un humain dans la boucle. Il suspend l’exécution, demande une décision, puis reprend par approved ou rejected. Rien n’est gardé en mémoire pendant l’attente : la demande, son délai et son rappel sont en base, si bien qu’un redémarrage du serveur ne perd rien.

Le nœud lui-même n’agit pas hors du produit : l’action à valider (envoyer une réponse, écrire dans un CRM) se place sur la branche approved. Le refus étant lui aussi une branche, vous pouvez le traiter (étiqueter le mail, prévenir un collègue) au lieu d’aboutir à un cul-de-sac. Pour attendre une durée ou un événement extérieur plutôt qu’une personne, utilisez Attendre. Voir aussi Revue et approbations.

Qui décide, et comment.

  • Qui reçoit la demande. Le membre pour qui l’exécution tourne, c’est-à-dire le propriétaire du workflow. La demande est un mail envoyé depuis la boîte de ce membre vers cette même adresse : la boîte du mail déclencheur s’il y en a un, sinon la première boîte connectée du membre. Son objet commence par [Approbation], suivi de la question.
  • Décider depuis le mail. Le mail contient deux boutons, Approuver et Rejeter. Chacun est un lien portant un jeton secret à usage unique : <PUBLIC_BASE_URL>/api/v1/approvals/t/<jeton>/approve (ou /reject). Un clic enregistre la décision et affiche une page de confirmation, sans connexion. Les liens ne fonctionnent qu’une fois : un second clic affiche la décision déjà acquise.
  • Décider dans l’application. Les demandes en attente apparaissent dans Activité → À traiter, avec les boutons Approuver et Rejeter, et une notification est publiée à l’arrivée d’une demande. L’API expose la même file (GET /api/v1/approvals) et la même décision (POST /api/v1/approvals/:id/decide).
  • Rappel. Par défaut, un mail de rappel, préfixé Rappel :, part à la moitié du délai. L’administrateur règle cette fraction avec APPROVAL_REMINDER_FRACTION (0 désactive les rappels ; voir les variables d’environnement).
  • Délai. Si personne ne répond à temps, le produit tranche seul selon « Sans réponse » : Rejeter par défaut, pour qu’une demande oubliée ne devienne jamais un envoi. Le délai va de 1 à 720 heures (30 jours), 48 heures par défaut.

Une décision est définitive : la première enregistrée l’emporte, quel que soit le canal.

En bref ​

  • Type : flow.approval · version 1
  • Catégorie : Logique
  • Nature : Étape — s’exécute pendant 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
  • Entrées : main
  • Sorties : approved, rejected

Paramètres ​

title ​

Question — La phrase que l’approbateur lit en premier. Accepte des expressions {{ }} — citez le client, le montant, l’objet.

  • Type : Texte (string)
  • Requis : Oui
  • 200 caractères au plus
  • Exemple : Valider l’envoi du devis à {{ email.from.name }}
  • Expressions : {{ }} accepté

details ​

Détails — Ce qu’il faut avoir sous les yeux pour trancher : le brouillon rédigé, le montant extrait, l’historique. Accepte des expressions {{ }}.

  • Type : Texte long (text)
  • Requis : Non
  • Défaut : "" (vide)
  • 5000 caractères au plus
  • Exemple : Brouillon proposé : {{ data.compose_1.message.bodyText }}
  • Expressions : {{ }} accepté

timeoutMs ​

Délai de réponse — Passé ce délai, le workflow tranche tout seul selon le réglage ci-dessous. L’exécution ne reste jamais en attente indéfiniment.

  • Type : Durée (duration)
  • Requis : Non
  • Défaut : 2 jours (172800000)
  • Stockée en millisecondes, saisie en heures ou jours
  • De 1 heure à 30 jours

onTimeout ​

Sans réponse

  • Type : Un choix (options)
  • Requis : Oui
  • Défaut : reject
  • Options :
    • reject — Rejeter : La branche « rejeté » est prise. Le défaut : une demande oubliée ne doit pas devenir un envoi.
    • approve — Approuver : La branche « approuvé » est prise. À réserver aux actions sans conséquence.

Sorties ​

  • approved — Emprunté quand la demande est approuvée — ou quand le délai expire avec « Sans réponse » réglé sur Approuver. En essai, toujours emprunté.
  • rejected — Emprunté quand la demande est rejetée — ou quand le délai expire avec « Sans réponse » réglé sur Rejeter (le défaut).

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.<step>.status }} — string. pending : l’état écrit à l’envoi de la demande. Il n’est pas mis à jour par la décision ; c’est la branche empruntée qui donne l’issue.
  • {{ data.<step>.title }} — string. La question, rendue.
  • {{ data.<step>.details }} — string. Les détails, rendus. Absent s’ils sont vides.
  • {{ data.<step>.decision }} — string. Essai uniquement : toujours approved.
  • {{ data.<step>.simulated }} — boolean. Essai uniquement : true.
  • {{ data.<step>.timeoutMs }} — number. Essai uniquement : le délai qui se serait appliqué, en millisecondes, après bornage.
  • {{ data.<step>.onTimeout }} — string. Essai uniquement : reject ou approve, la décision que le délai aurait prise.
  • {{ data.<step>.effect }} — string. Essai uniquement : une phrase décrivant la demande qui aurait été envoyée.

Example ​

Relire vous-même une réponse rédigée par l’IA avant qu’elle parte. Après Rédiger (IA), ajoutez un nœud Approbation :

title:        Envoyer le devis à {{ email.from.name }} ?
details:      Réponse proposée :
              {{ data.rediger.message }}
timeoutMs:    86400000 (24 h)
onTimeout:    reject

Reliez approved à Envoyer et rejected à une étape Marquer. Le membre reçoit [Approbation] Envoyer le devis à Jeanne Martin ?, clique sur Approuver depuis son téléphone, et l’exécution reprend par approved.

Tips ​

  • En essai, le nœud n’attend personne : il prend approved immédiatement, n’envoie rien et consigne la demande qu’il aurait envoyée (simulated, effect).
  • Un membre sans boîte connectée ne reçoit aucun mail ; la demande reste décidable dans l’application.
  • Quand un administrateur a suspendu les envois, le mail de demande est retenu et part à la reprise des envois. La demande reste décidable dans l’application entre-temps.
  • Certaines passerelles de sécurité ouvrent automatiquement les liens des mails entrants. Si c’est le cas dans votre organisation, décidez plutôt dans l’application et laissez « Sans réponse » sur Rejeter.
  • title et details sont templatables : citez le client, le montant et le brouillon pour que l’approbateur puisse trancher depuis le mail seul.