Mankomail

Wait ​

Suspends the execution — from a minute to several years. Nothing is kept in memory: the wait survives restarts.

The Wait node suspends the run for a while, from one minute to several years, and resumes it later. Nothing is kept in memory: the deadline is stored in the database and survives restarts and deployments. Waiting runs are listed in Activity → Waiting.

Three modes are available:

  • For a duration: minutes, hours, days, weeks, months or years. Months and years are civil: 31 January + 1 month is 28 (or 29) February, and "+ 1 year" lands on the same day of the month, leap years and daylight saving time included.
  • Until a date: a date from the data (an extracted field, a table row), plus an optional offset (negative to anticipate) and a time of day. A date alone such as 2027-05-04 is read at midnight in the chosen time zone, not in UTC. Any full ISO 8601 instant is accepted too.
  • In business days or hours: weekends, public holidays and company closures are skipped, using the organisation calendar set in Administration → Business calendar (by default: Monday to Friday, 09:00–18:00, French public holidays, Europe/Paris). 48 business hours span more than five calendar days.

To compute a date without waiting, for instance to write it in a table, use Compute a date: it uses the same calendar and the same rules. To wait for a person's decision, use Approval.

Early wake-up. A follow-up sent after the awaited document has arrived by another route is worse than no follow-up. With "Wake up before the deadline if…", the wait ends early and leaves through event:

  • A reply lands in the thread: a new message in the thread of the triggering email, detected when the mailbox syncs. Messages sent from the mailbox itself never count, nor does the triggering email. "Only if the reply comes from" accepts a full address (jane@client.example) or a domain written with its @ (@client.example). This option needs a triggering email: publishing refuses it on a workflow started by a schedule or a webhook.
  • A signal carries the key: another workflow emits a signal with the same correlation key through Emit a signal, or a program does so through the API. A signal can also cancel the waiting run altogether.

A waiting run can also be resumed by hand from Activity → Waiting: "As if the deadline was reached" (branch main) or "As if the event had arrived" (branch event, only when early wake-up is set).

At a glance ​

  • Type: flow.wait · version 1
  • Category: Logic
  • Kind: Step — one stage of a run
  • Effect: No external effect (none) — nothing is written outside Mankomail; safe to replay
  • Needs a carrier email: No
  • Connection: None
  • Inputs: main
  • Outputs: Computed from the parameters (with the default parameters: main)

Parameters ​

mode ​

Wait

  • Type: One choice (options)
  • Required: Yes
  • Default: duration
  • Options:
    • duration — For a duration: From minutes to years. Months and years are civil: "+ 1 year" lands on the same day of the month.
    • until — Until a date: A date taken from the data ({{ data.extract_1.dueDate }}, a table row), with an offset and a time of day.
    • business — In business days or hours: Weekends, public holidays and company closures skipped. The calendar is set in the administration screen.

duration ​

Duration — How long. The cap is set by the instance (two years by default).

  • Type: Number (number)
  • Required: Yes
  • Default: 1
  • Whole number, from 1 to 100000
  • Shown when: mode is duration

unit ​

Unit

  • Type: One choice (options)
  • Required: Yes
  • Default: hours
  • Options:
    • minutes — minutes
    • hours — hours
    • days — days
    • weeks — weeks
    • months — months: Civil months: 31 January + 1 month is 28 (or 29) February, never 3 March.
    • years — years: Civil years: the same day of the month next year, leap years and DST included.
  • Shown when: mode is duration

until ​

Reference date — A date from the data — an extracted field, a table row, the date of a deed. 2027-05-04 is read at midnight in the time zone below, never in UTC.

  • Type: Text (string)
  • Required: Yes
  • Default: "" (empty)
  • 200 characters at most
  • Example: {{ data.extract_1.deedDate }}
  • Shown when: mode is until
  • Expressions: {{ }} accepted

offsetAmount ​

Offset — Added to the reference date. Negative to anticipate: "10 days before the deadline".

  • Type: Number (number)
  • Required: No
  • Default: 0
  • Whole number, from -1000 to 1000
  • Shown when: mode is until

offsetUnit ​

Offset unit

  • Type: One choice (options)
  • Required: No
  • Default: days
  • Options:
    • days — days
    • weeks — weeks
    • months — months
    • years — years
  • Shown when: mode is until

pastPolicy ​

If the date has already passed — A date extracted from an old document can be behind us. Not a detail: deciding nothing means sending the follow-up right away.

  • Type: One choice (options)
  • Required: Yes
  • Default: continue
  • Options:
    • continue — Continue right away: The normal output, without waiting.
    • fail — Fail: The step fails and the failure surfaces: preferable when a past date means the data is wrong.
    • port — Take the "already passed" branch: Opens a third port, to handle that case separately.
  • Shown when: mode is until

businessAmount ​

How many

  • Type: Number (number)
  • Required: Yes
  • Default: 2
  • Whole number, from 0 to 3000
  • Shown when: mode is business

businessUnit ​

Business unit

  • Type: One choice (options)
  • Required: Yes
  • Default: businessDays
  • Options:
    • businessDays — business days: Working days, excluding public holidays and closures.
    • businessHours — business hours: Opening hours consumed day after day: 48 business hours is more than five days.
  • Shown when: mode is business

atClock ​

Wake-up time — HH:MM format. Empty: the computed time. A follow-up sent at 3:47 a.m. is noticed.

  • Type: Text (string)
  • Required: No
  • Default: "" (empty)
  • 80 characters at most
  • Example: 09:00
  • Expressions: {{ }} accepted

timezone ​

Time zone — IANA name (Europe/Paris). Empty: the one of the instance calendar.

  • Type: Text (string)
  • Required: No
  • Default: "" (empty)
  • 100 characters at most
  • Example: Europe/Paris
  • Shown under “Advanced” in the editor
  • Expressions: {{ }} accepted

onlyBusinessHours ​

Only wake during business hours — A deadline falling at night, on a Sunday or a public holiday is pushed back to the next opening — never brought forward.

  • Type: Yes / no (boolean)
  • Required: No
  • Default: false

earlyWake ​

Wake up before the deadline if… — Without this, a follow-up is sent even when the document arrived meanwhile through another path. The output is then the "event received" branch.

  • Type: Several choices (multiOptions)
  • Required: No
  • Default: []
  • Options:
    • reply — A reply lands in the thread: The thread of the triggering email. The mirror detects it on sync, with no extra polling. Without a triggering email (schedule, webhook) there is no thread: publishing refuses it.
    • signal — A signal carries the key below: Emitted by another workflow ("Emit a signal" node) or by the API. It can also cancel the wait.
  • Needs a carrier email for: reply

signalKey ​

Correlation key — What links the wait to the awaited fact: case:{{ data.extract_1.reference }}:documents-received. Organisation-wide scope.

  • Type: Text (string)
  • Required: No
  • Default: "" (empty)
  • 200 characters at most
  • Example: case:{{ data.extract_1.reference }}:documents-received
  • Shown when: earlyWake includes signal
  • Expressions: {{ }} accepted

replyFrom ​

Only if the reply comes from — An address or a domain (@client.com). Empty: any third-party reply wakes the wait.

  • Type: Text (string)
  • Required: No
  • Default: "" (empty)
  • 200 characters at most
  • Shown when: earlyWake includes reply
  • Expressions: {{ }} accepted

Outputs ​

Computed from the parameters.

  • main — Taken when the deadline is reached — or right away when there is nothing to wait for (delay under a minute, past date with policy "Continue right away").
  • event — Present when "Wake up before the deadline if…" is set. Taken when a reply lands in the thread or a matching signal arrives before the deadline.
  • past — Present in "Until a date" mode with the policy "Take the “already passed” branch". Taken when the computed date is already behind us.

Data produced ​

What this node adds to the run data, and how to read it in an expression. <step> stands for the step key: the node name turned into an identifier (see Data and expressions).

  • {{ data.<step>.status }} — string. After a live wait: resumed (deadline reached) or event (woken early). Without suspension: immediate (delay under a minute) or past (date already passed). In a test run: skipped.
  • {{ data.<step>.resumedAt }} — string. After a live wait: the ISO 8601 instant the wait ended.
  • {{ data.<step>.wokenBy }} — string. After a live wait ended early: event. Absent otherwise.
  • {{ data.<step>.plannedFor }} — string. The ISO 8601 deadline that was scheduled (or computed, when the node did not suspend).
  • {{ data.<step>.mode }} — string. Without suspension or in a test run: duration, until or business.
  • {{ data.<step>.waitMs }} — number. Without suspension or in a test run: the delay retained, in milliseconds, after the instance cap.
  • {{ data.<step>.capped }} — boolean. Without suspension or in a test run: true when the instance cap shortened the delay (with cappedToMs). Absent otherwise.
  • {{ data.<step>.shiftedToBusinessHours }} — boolean. Without suspension or in a test run: true when "Only wake during business hours" pushed the deadline back. Absent otherwise.
  • {{ data.<step>.signalKey }} — string. Without suspension or in a test run: the rendered correlation key, when the wait listens for a signal.
  • {{ data.<step>.earlyWake }} — array. Without suspension or in a test run: the early-wake sources, reply and/or signal, when set.
  • {{ data.<step>.simulated }} — boolean. Test runs only: true, with effect describing the wait that would have happened.
  • {{ data.<step>.summary }} — string. A one-line summary in the member's language, e.g. 'Wait finished.' (with summaryKey and summaryParams, its untranslated form).

Example ​

Chase a client who has not sent the requested documents, unless they reply or the documents arrive through another workflow. After sending the request:

mode:              business
businessAmount:    8
businessUnit:      businessDays
atClock:           09:00
earlyWake:         [reply, signal]
signalKey:         case:{{ data.extract.reference }}:documents-received
replyFrom:         @client.example

Connect main to the follow-up email and event to the step that files the documents. If the client answers in the thread on day 3, the run resumes on event with {{ data.<step>.status }} = event; otherwise it resumes on main eight business days later at 09:00 with status = resumed.

Tips ​

  • Limits. A wait is capped by the instance: two years by default, set by the administrator with WAIT_MAX_DAYS (see environment variables). A longer request is shortened to the cap (capped).
  • Under a minute, no wait. A computed delay shorter than one minute does not suspend the run: the node continues on main with status immediate. This does not apply when early wake-up is set: such a wait is installed even for a few seconds.
  • Past dates (mode "Until a date"): choose the policy deliberately. "Continue right away" (default) takes main immediately, which sends a follow-up at once; "Fail" makes the step fail with node_invalid_param; "Take the “already passed” branch" uses the past port.
  • Replays never push the deadline. The deadline is anchored on the moment the step started, so a retried step keeps the same deadline.
  • Unreadable values fail. An unreadable date, a time not written HH:MM, or an unknown time zone makes the step fail with node_invalid_param. Waking on a signal without a correlation key fails the same way.
  • Data after the wait. When the wait really suspends, the step data visible downstream is the resumed form (status, resumedAt, wokenBy, plannedFor, summary); the planning details (mode, waitMs…) are only kept when the node did not suspend.
  • In test runs the node never sleeps: it continues on main immediately with status skipped and describes the wait it would have made.
  • A wait that listens for a reply in a run with no triggering email simply waits for its deadline.
  • With business hours as the unit, "Wake-up time" is ignored: a time of day makes no sense on a count of opening hours. It applies to business days.