Skip to main content
Version: 5.1

Send a Data Event

A run parked on an await data event stays there until something delivers the value it is waiting for, or the timeout is reached. That delivery is a Send Data Event step, and it usually lives in the entry point a partner system or a person calls back on: the payment gateway's webhook, the resource where an employee uploads the missing document, a scheduled automation that posts the day's file.

A POST payment resource holding a single Send to paymentInfo step, drawn with a dashed arrow across to the orderWorkflow it delivers intoA POST payment resource holding a single Send to paymentInfo step, drawn with a dashed arrow across to the orderWorkflow it delivers into

The delivery does not create a run. It resumes one, so it needs the workflow ID that starting the run returned.

Send one from an integration​

  1. In the trigger artifact flow design, click +.

  2. In the node panel, under Workflow, click Send Data Event.

  3. Fill in the form:

    FieldRequiredDescription
    Workflow NameYesThe workflow to deliver into. The dropdown lists every workflow in the project.
    Target Workflow IdYesWhich run to resume. This is the ID that starting the run returned.
    Data NameYesThe event to fill. The dropdown lists the data events declared by the workflow chosen above, so the two cannot drift apart.
    DataYesThe value to deliver. It has to match the type the event declares.
  4. Click Save.

Adding a Send Data Event step and choosing the workflow and its data eventAdding a Send Data Event step and choosing the workflow and its data event

Anyone with the ID can deliver​

There is nothing special about the integration that started the run. Any integration that can reach the runtime and holds the workflow ID can fill the event, which is what makes a callback from a third party work: hand out the ID when the run starts, and the delivery can arrive from anywhere, minutes or weeks later.

That also means the ID is worth guarding. A run whose ID was lost keeps waiting, and no code can resume it.

The ID is not an authorization check

Holding the workflow ID is all it takes to fill the event, so the resource that accepts the delivery is what has to authenticate and authorize the caller. Protect it the way you would any other write endpoint, and do not treat a workflow ID as a credential.

Next steps​