Mankomail

Attendre ​

Suspend l’exécution — d’une minute à plusieurs années. Rien n’est gardé en mémoire : l’attente survit aux redémarrages.

Le nœud Attendre suspend l’exécution pendant un certain temps, d’une minute à plusieurs années, puis la reprend. Rien n’est gardé en mémoire : l’échéance est en base et survit aux redémarrages comme aux déploiements. Les exécutions en attente sont listées dans Activité → Attentes.

Trois modes sont proposés :

  • Pendant une durée : minutes, heures, jours, semaines, mois ou années. Les mois et les années sont civils : le 31 janvier + 1 mois donne le 28 (ou 29) février, et « + 1 an » retombe sur le même quantième, années bissextiles et changements d’heure compris.
  • Jusqu’à une date : une date venue de la donnée (un champ extrait, une ligne de table), avec un décalage facultatif (négatif pour anticiper) et une heure. Une date seule comme 2027-05-04 est lue à minuit dans le fuseau choisi, jamais en UTC. Un instant ISO 8601 complet est aussi accepté.
  • En jours ou heures ouvrés : week-ends, jours fériés et fermetures de l’entreprise sont sautés, selon le calendrier de l’organisation réglé dans Administration → Calendrier ouvré (par défaut : du lundi au vendredi, 09:00–18:00, jours fériés français, Europe/Paris). 48 heures ouvrées couvrent plus de cinq jours calendaires.

Pour calculer une date sans attendre, par exemple pour l’écrire dans une table, utilisez Calculer une date : il utilise le même calendrier et les mêmes règles. Pour attendre la décision d’une personne, utilisez Approbation.

Le réveil anticipé. Une relance envoyée alors que la pièce attendue est arrivée par un autre chemin est pire que pas de relance du tout. Avec « Se réveiller avant l’échéance si… », l’attente se termine plus tôt et sort par event :

  • Une réponse arrive dans le fil : un nouveau message dans le fil du mail déclencheur, détecté à la synchronisation de la boîte. Les messages envoyés par la boîte elle-même ne comptent jamais, pas plus que le mail déclencheur. « Seulement si la réponse vient de » accepte une adresse complète (jeanne@client.example) ou un domaine écrit avec son @ (@client.example). Cette option exige un mail déclencheur : la publication la refuse sur un workflow lancé par une planification ou un webhook.
  • Un signal porte la clé : un autre workflow émet un signal de même clé de corrélation avec Émettre un signal, ou un programme le fait par l’API. Un signal peut aussi annuler purement et simplement l’exécution en attente.

Une exécution en attente peut aussi être reprise à la main depuis Activité → Attentes : « Comme si l’échéance était atteinte » (branche main) ou « Comme si l’événement était arrivé » (branche event, seulement si le réveil anticipé est renseigné).

En bref ​

  • Type : flow.wait · 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 : Calculées depuis les paramètres (avec les paramètres par défaut : main)

Paramètres ​

mode ​

Attendre

  • Type : Un choix (options)
  • Requis : Oui
  • Défaut : duration
  • Options :
    • duration — Pendant une durée : De quelques minutes à plusieurs années. Les mois et les années sont civils : « + 1 an » retombe sur le même quantième.
    • until — Jusqu’à une date : Une date venue de la donnée ({{ data.extract_1.echeance }}, une ligne de table), avec un décalage et une heure.
    • business — En jours ou heures ouvrés : Week-ends, jours fériés du pays et fermetures de l’entreprise sautés. Le calendrier se règle dans l’administration.

duration ​

Durée — Combien de temps. Le plafond est réglé par l’instance (deux ans par défaut).

  • Type : Nombre (number)
  • Requis : Oui
  • Défaut : 1
  • Nombre entier, de 1 à 100000
  • Affiché quand : mode vaut duration

unit ​

Unité

  • Type : Un choix (options)
  • Requis : Oui
  • Défaut : hours
  • Options :
    • minutes — minutes
    • hours — heures
    • days — jours
    • weeks — semaines
    • months — mois : Des mois civils : le 31 janvier + 1 mois donne le 28 (ou 29) février, jamais le 3 mars.
    • years — années : Des années civiles : le même quantième l’année suivante, années bissextiles et changements d’heure compris.
  • Affiché quand : mode vaut duration

until ​

Date de référence — Une date de la donnée — un champ extrait, une ligne de table, la date d’un acte. 2027-05-04 est lue à minuit dans le fuseau ci-dessous, jamais en UTC.

  • Type : Texte (string)
  • Requis : Oui
  • Défaut : "" (vide)
  • 200 caractères au plus
  • Exemple : {{ data.extract_1.dateActe }}
  • Affiché quand : mode vaut until
  • Expressions : {{ }} accepté

offsetAmount ​

Décalage — Ajouté à la date de référence. Négatif pour anticiper : « 10 jours avant l’échéance ».

  • Type : Nombre (number)
  • Requis : Non
  • Défaut : 0
  • Nombre entier, de -1000 à 1000
  • Affiché quand : mode vaut until

offsetUnit ​

Unité du décalage

  • Type : Un choix (options)
  • Requis : Non
  • Défaut : days
  • Options :
    • days — jours
    • weeks — semaines
    • months — mois
    • years — années
  • Affiché quand : mode vaut until

pastPolicy ​

Si la date est déjà passée — Une date extraite d’un vieux document peut être derrière nous. Ce n’est pas un détail : ne rien décider revient à envoyer la relance immédiatement.

  • Type : Un choix (options)
  • Requis : Oui
  • Défaut : continue
  • Options :
    • continue — Continuer tout de suite : La sortie normale, sans attendre.
    • fail — Échouer : L’étape échoue et l’échec remonte : à préférer quand une date passée signale une donnée fausse.
    • port — Sortir par la branche « déjà passée » : Ouvre un troisième port, pour traiter ce cas à part.
  • Affiché quand : mode vaut until

businessAmount ​

Combien

  • Type : Nombre (number)
  • Requis : Oui
  • Défaut : 2
  • Nombre entier, de 0 à 3000
  • Affiché quand : mode vaut business

businessUnit ​

Unité ouvrée

  • Type : Un choix (options)
  • Requis : Oui
  • Défaut : businessDays
  • Options :
    • businessDays — jours ouvrés : Les jours travaillés, hors jours fériés et fermetures.
    • businessHours — heures ouvrées : Les heures d’ouverture consommées une journée après l’autre : 48 h ouvrées font plus de cinq jours.
  • Affiché quand : mode vaut business

atClock ​

Heure du réveil — Format HH:MM. Vide : l’heure du calcul. Une relance qui part à 3 h 47 du matin se voit.

  • Type : Texte (string)
  • Requis : Non
  • Défaut : "" (vide)
  • 80 caractères au plus
  • Exemple : 09:00
  • Expressions : {{ }} accepté

timezone ​

Fuseau horaire — Nom IANA (Europe/Paris). Vide : celui du calendrier de l’instance.

  • Type : Texte (string)
  • Requis : Non
  • Défaut : "" (vide)
  • 100 caractères au plus
  • Exemple : Europe/Paris
  • Rangé sous « Avancé » dans l’éditeur
  • Expressions : {{ }} accepté

onlyBusinessHours ​

Ne réveiller que pendant les heures ouvrées — Une échéance qui tombe la nuit, un dimanche ou un jour férié est repoussée à la prochaine ouverture — jamais avancée.

  • Type : Oui / non (boolean)
  • Requis : Non
  • Défaut : false

earlyWake ​

Se réveiller avant l’échéance si… — Sans ça, une relance part même quand la pièce est arrivée entre-temps par un autre chemin. La sortie est alors la branche « événement reçu ».

  • Type : Plusieurs choix (multiOptions)
  • Requis : Non
  • Défaut : []
  • Options :
    • reply — Une réponse arrive dans le fil : Le fil du mail déclencheur. Le miroir le détecte à la synchronisation, sans rien interroger de plus. Sans mail porteur (planification, webhook), il n’y a pas de fil : la publication le refuse.
    • signal — Un signal porte la clé ci-dessous : Émis par un autre workflow (nœud « Émettre un signal ») ou par l’API. Il peut aussi annuler l’attente.
  • Exige un mail porteur pour : reply

signalKey ​

Clé de corrélation — Ce qui relie l’attente au fait attendu : dossier:{{ data.extract_1.reference }}:pieces-recues. Portée organisation.

  • Type : Texte (string)
  • Requis : Non
  • Défaut : "" (vide)
  • 200 caractères au plus
  • Exemple : dossier:{{ data.extract_1.reference }}:pieces-recues
  • Affiché quand : earlyWake contient signal
  • Expressions : {{ }} accepté

replyFrom ​

Seulement si la réponse vient de — Une adresse ou un domaine (@client.fr). Vide : n’importe quelle réponse d’un tiers réveille l’attente.

  • Type : Texte (string)
  • Requis : Non
  • Défaut : "" (vide)
  • 200 caractères au plus
  • Affiché quand : earlyWake contient reply
  • Expressions : {{ }} accepté

Sorties ​

Calculées depuis les paramètres.

  • main — Emprunté quand l’échéance est atteinte — ou tout de suite quand il n’y a rien à attendre (délai de moins d’une minute, date passée avec la politique « Continuer tout de suite »).
  • event — Présent quand « Se réveiller avant l’échéance si… » est renseigné. Emprunté quand une réponse arrive dans le fil ou qu’un signal correspondant arrive avant l’échéance.
  • past — Présent en mode « Jusqu’à une date » avec la politique « Sortir par la branche “déjà passée” ». Emprunté quand la date calculée est déjà derrière nous.

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. Après une vraie attente : resumed (échéance atteinte) ou event (réveil anticipé). Sans suspension : immediate (délai de moins d’une minute) ou past (date déjà passée). En essai : skipped.
  • {{ data.<step>.resumedAt }} — string. Après une vraie attente : l’instant ISO 8601 de la fin de l’attente.
  • {{ data.<step>.wokenBy }} — string. Après une attente terminée avant l’heure : event. Absent sinon.
  • {{ data.<step>.plannedFor }} — string. L’échéance ISO 8601 planifiée (ou calculée, quand le nœud n’a pas suspendu).
  • {{ data.<step>.mode }} — string. Sans suspension ou en essai : duration, until ou business.
  • {{ data.<step>.waitMs }} — number. Sans suspension ou en essai : le délai retenu, en millisecondes, après plafond de l’instance.
  • {{ data.<step>.capped }} — boolean. Sans suspension ou en essai : true quand le plafond de l’instance a raccourci le délai (avec cappedToMs). Absent sinon.
  • {{ data.<step>.shiftedToBusinessHours }} — boolean. Sans suspension ou en essai : true quand « Ne réveiller que pendant les heures ouvrées » a repoussé l’échéance. Absent sinon.
  • {{ data.<step>.signalKey }} — string. Sans suspension ou en essai : la clé de corrélation rendue, quand l’attente guette un signal.
  • {{ data.<step>.earlyWake }} — array. Sans suspension ou en essai : les sources de réveil anticipé, reply et/ou signal, si renseignées.
  • {{ data.<step>.simulated }} — boolean. Essai uniquement : true, avec effect qui décrit l’attente qui aurait eu lieu.
  • {{ data.<step>.summary }} — string. Un résumé d’une ligne dans la langue du membre, par exemple « Attente terminée. » (avec summaryKey et summaryParams, sa forme non traduite).

Example ​

Relancer un client qui n’a pas envoyé les pièces demandées, sauf s’il répond ou si les pièces arrivent par un autre workflow. Après l’envoi de la demande :

mode:              business
businessAmount:    8
businessUnit:      businessDays
atClock:           09:00
earlyWake:         [reply, signal]
signalKey:         dossier:{{ data.extraire.reference }}:pieces-recues
replyFrom:         @client.example

Reliez main au mail de relance et event à l’étape qui classe les pièces. Si le client répond dans le fil au troisième jour, l’exécution reprend par event avec {{ data.<step>.status }} = event ; sinon elle reprend par main huit jours ouvrés plus tard à 09:00, avec status = resumed.

Tips ​

  • Bornes. Une attente est plafonnée par l’instance : deux ans par défaut, réglés par l’administrateur avec WAIT_MAX_DAYS (voir les variables d’environnement). Une demande plus longue est ramenée au plafond (capped).
  • Moins d’une minute, pas d’attente. Un délai calculé de moins d’une minute ne suspend pas l’exécution : le nœud continue par main avec le status immediate. Cela ne s’applique pas quand le réveil anticipé est renseigné : une telle attente s’installe même pour quelques secondes.
  • Dates passées (mode « Jusqu’à une date ») : choisissez la politique en connaissance de cause. « Continuer tout de suite » (défaut) prend main immédiatement, donc envoie la relance aussitôt ; « Échouer » fait échouer l’étape avec node_invalid_param ; « Sortir par la branche “déjà passée” » utilise le port past.
  • Une nouvelle tentative ne repousse jamais l’échéance. L’échéance est ancrée sur le moment où l’étape a commencé : une étape retentée garde la même échéance.
  • Les valeurs illisibles échouent. Une date illisible, une heure qui ne s’écrit pas HH:MM ou un fuseau inconnu font échouer l’étape avec node_invalid_param. Se réveiller sur un signal sans clé de corrélation échoue de la même façon.
  • Les données après l’attente. Quand l’attente suspend réellement, les données d’étape visibles en aval sont celles de la reprise (status, resumedAt, wokenBy, plannedFor, summary) ; le détail du calcul (mode, waitMs…) n’est conservé que lorsque le nœud n’a pas suspendu.
  • En essai, le nœud ne dort jamais : il continue immédiatement par main avec le status skipped et décrit l’attente qu’il aurait faite.
  • Une attente qui guette une réponse dans une exécution sans mail déclencheur attend simplement son échéance.
  • Avec l’unité heures ouvrées, « Heure du réveil » est ignorée : une heure de la journée n’a pas de sens sur un décompte d’heures d’ouverture. Elle s’applique aux jours ouvrés.