adverse_action.triggered

An adverse-action notice was sent (or the pre-adverse waiting period started)

Emitted by the AdverseAction node when a notice goes out. For the two-step employment flow (notice_stage: pre_adverse) the execution then enters waiting until resume_at, when the post-adverse notice is sent. For single-notice flows (notice_stage: final) it is immediately followed by adverse_action.completed.

Payload

id string (uuid) required
event string required One of adverse_action.triggered
created_at string (date-time) required
data object required
- workflow_execution_id integer required
- workflow_id integer required
- node_id string required The `AdverseAction` node's id in the definition.
- external_reference string
- flow string required `employment` for the two-step pre/post flow; otherwise the workflow's use case (e.g. `tenant_screening`).
- notice_stage string required One of pre_adverse final
- sent_to string Recipient address the notice was sent to.
- delivery_channels array of string `final` stage only: the channels used. Currently always `digital` (physical mail is not yet enabled).
- triggered_at string (date-time)
- resume_at string (date-time) `pre_adverse` only: when the post-adverse notice will be sent.
- status string required One of waiting completed

How to handle it

Answer 2xx as soon as the delivery is stored and do the real work on a queue. Any other response, a connection error or a timeout (5 s connect, 10 s read) counts as a failure: Cascades retries after 1m, 5m, 30m, 2h, 8h, 24h, then marks the delivery dead.
De-duplicate on the envelope's id — it is identical across retries and across every subscriber's copy of the same event — or on the X-Cascades-Delivery header, which names one delivery row.
Verify X-Cascades-Signature before you act on the body (next section).
Treat data as a pointer, not the record: read data.workflow_execution_id and call GET /executions/{id} for the current status, the decision and — with executions:read:full — the step_outputs.
This event carries no execution_mode. If your handler must tell test runs from live ones, join on workflow_execution_id and read input_context.execution_mode from the execution.

Verify before you trust it

Compute HMAC-SHA256(signing_secret, "<t>.<raw body>") and compare it in constant time with the v1 (or, during rotation, v0) value in X-Cascades-Signature. Samples are in the right-hand rail and in the verify webhooks guide.

Deliveries retry on any non-2xx response, so handle the same X-Cascades-Delivery id more than once safely. See all webhook events.