Mankomail

Emit a signal ​

Ends, elsewhere, the waits watching this key — so a client who already answered is never chased.

The Emit a signal node ends, elsewhere, the waits watching a correlation key. It answers a common problem: the document a follow-up is waiting for arrives through another thread, the contract is signed at the office, the offer is settled by phone. A Wait node set to wake on a signal is installed with a key, for instance case:PSD-2026-0142:documents-received; the workflow that learns the fact emits a signal with the same key, and every wait watching it ends.

Two actions are available:

  • Wake the waits (resume): the waits leave through their event port, so the planned follow-up is not sent and the run continues on the "event received" branch.
  • Cancel the waiting runs (cancel): the runs are cancelled; nothing that followed the wait runs. Choose this when the case is closed.

The key is any string chosen by you; the only requirement is that it is exactly the same on both sides. Its scope is the whole organisation. A program can emit the same signal through the API with an API key holding the signals:write scope.

At a glance ​

  • Type: flow.signal · version 1
  • Category: Logic
  • Kind: Step — one stage of a run
  • Effect: Writes outside (external_write) — writes outside Mankomail; described instead of performed during a test run
  • Needs a carrier email: No
  • Connection: None
  • Inputs: main
  • Outputs: main

Parameters ​

key ​

Correlation key — Exactly the same string as the one in the Wait node watching for this fact. Organisation-wide scope.

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

action ​

What the signal does

  • Type: One choice (options)
  • Required: Yes
  • Default: resume
  • Options:
    • resume — Wake the waits: They take their "event received" branch — so the planned follow-up is not sent.
    • cancel — Cancel the waiting executions: Nothing that followed the wait will run. Choose this when the case is closed.

payload ​

What the signal carries — Short values, readable by the woken wait under data.<node>.signal. Never an email body: the row is bounded and lives in the database.

  • Type: Key / value pairs (keyValue)
  • Required: No
  • Default: []
  • Shown when: action is resume
  • Expressions: {{ }} accepted

Outputs ​

  • main — Taken once the signal has been emitted, whether or not a wait matched it.

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>.key }} — string. The correlation key, rendered and trimmed.
  • {{ data.<step>.action }} — string. resume (wake the waits) or cancel (cancel the waiting runs).
  • {{ data.<step>.matched }} — number. How many waits were woken or cancelled by this emission. 0 means no wait was watching the key at that moment. Always 0 in a test run.
  • {{ data.<step>.signalId }} — string. The identifier of the recorded signal. Absent in a test run.
  • {{ data.<step>.duplicate }} — boolean. true when this step had already emitted the signal (a retried step): nothing was emitted again. Absent otherwise.
  • {{ data.<step>.simulated }} — boolean. Test runs only: true, with effect describing the signal that would have been emitted.
  • {{ data.<step>.summary }} — string. A one-line summary in the member's language, e.g. 'Signal emitted — 1 wait affected.' (with summaryKey and summaryParams).

Example ​

Workflow A sends a request for documents and waits ten business days, waking on the signal case:{{ data.extract.reference }}:documents-received. Workflow B is triggered by incoming emails carrying attachments and extracts the case reference. At its end, add Emit a signal:

key:    case:{{ data.read.reference }}:documents-received
action: resume

When B runs for case PSD-2026-0142, the wait of A for that case leaves through event, and {{ data.<step>.matched }} in B is 1.

Tips ​

  • A signal can arrive first. A signal emitted by this node remains valid for 24 hours (a signal emitted through the API follows SIGNAL_RETENTION_HOURS, 24 by default, see environment variables). A wait installed with that key during this window ends immediately. Conversely, reusing the same key for an unrelated wait within that window ends it at once: include a case reference in the key.
  • Exactly once. A retried step does not emit the signal a second time; it reports duplicate.
  • matched is 0. Nothing was waiting at that moment: check that the keys are identical on both sides, including case and separators.
  • Test runs. The node only describes the signal it would have emitted: emitting it for real would wake or cancel real runs.
  • An empty key (after rendering) makes the step fail with node_invalid_param.