Skip to content

Publish events

A workflow can send a message to the outside world with the EVENT task. The task takes resolved workflow data, adds durable metadata, and publishes the message to a configured provider such as Kafka or SQS. The publish is a normal step in the execution, so it is recorded and retried like any other task. Use KAFKA_PUBLISH only when you need Kafka-specific producer controls.

Workflow event publication flow A workflow sends resolved input to the Event task, which publishes to a configured sink for a broker and consumer. Kafka Publish is a separate Kafka-specific option. Workflowresolved input EVENTmetadata Configured sinkbroker or consumer KAFKA_PUBLISH: Kafka-specific branch

Choose the task

Use When it fits What it gives you
EVENT You want a provider-neutral message to an enabled event-queue provider. A common sink model, workflow metadata, a stable message identity, and event-handler compatibility.
KAFKA_PUBLISH Your contract needs Kafka-specific keys, headers, serializers, or producer controls. Direct Kafka topic publishing with Kafka-specific configuration.

Do not use KAFKA_PUBLISH just because the destination happens to be Kafka. Prefer EVENT unless those Kafka-specific controls are required.

Name the destination

An EVENT sink is provider:<provider-specific destination>. In OSS, enabled provider keys include conductor, kafka, sqs, nats, jsm, nats_stream, amqp_queue, and amqp_exchange.

The conductor provider expands a short sink so it is namespaced by the workflow:

Sink in the definition Expanded sink for workflow order_workflow
conductor conductor:order_workflow:<taskReferenceName>
conductor:order-status conductor:order_workflow:order-status

An event handler must subscribe to the expanded name. Kafka topics, SQS queue URLs, NATS subjects, and AMQP destinations retain the grammar required by their provider.

On Orkes, select the managed broker integration configured for the tenant and use its integration-qualified sink naming. That configuration is distinct from the OSS provider keys above: do not copy an OSS provider prefix into an Orkes integration name, or assume an Orkes integration name is portable to OSS.

What is published

Conductor resolves inputParameters, then adds these fields to the published JSON:

Field Value
workflowInstanceId Parent workflow execution ID
workflowType / workflowVersion Parent workflow name and version
correlationId Parent correlation ID
taskToDomain Parent task-domain map

The task output also includes event_produced, the expanded sink, but that field is not sent as part of the broker message. The Event task ID is the broker message identity; consumers can use it as a durable duplicate-detection key.

Publish an order-status event

{
  "name": "publish_order_status",
  "taskReferenceName": "publish_order_status",
  "type": "EVENT",
  "sink": "conductor:order-status",
  "inputParameters": {
    "orderId": "${workflow.input.orderId}",
    "status": "READY"
  },
  "asyncComplete": false
}

With asyncComplete: false, a successful broker publish completes the task. With asyncComplete: true, publication succeeds but the task remains IN_PROGRESS until an external task update, or an event-handler complete_task or fail_task action, resolves it.

Production guidance

  • Delivery: Treat broker delivery as at-least-once. Consumer actions and any side effects must be idempotent.
  • Observability: Monitor event_queue_depth, the event_queue_messages_* counters, then inspect the downstream workflow or task result.
  • Identity: Preserve the broker message ID and use the Event task ID for duplicate detection; do not invent a new random key for retries.

Next steps

Route the published event → Receive HTTP callbacks instead → EVENT task reference → KAFKA_PUBLISH reference →