Event-Driven Orchestration
Event-driven orchestration connects workflows to the messages around them. A workflow can publish to a broker, an incoming message or webhook can start or advance workflows, and a signal can resume one specific execution that is waiting. Each page in this section covers one of those directions, and the table below routes you to the right one.
| Need | Start here | Availability |
|---|---|---|
| Publish workflow data to a queue or broker | Publish events | OSS and Orkes |
| Consume a broker message and start or update workflow work | Consume and route events | OSS and Orkes |
| Receive an HTTP callback from an external service | Incoming webhooks | Orkes only |
Continue a workflow blocked on WAIT |
Send signals to workflows | OSS and Orkes |
| Notify external systems when executions change state | Workflow status events | OSS and Orkes |
EVENT publishes messages; an event handler consumes and routes them. A webhook is HTTP ingress, not a general-purpose event handler. A signal changes an existing workflow and does not create a new execution.
Broker provider matrix
Provider support depends on the Conductor distribution and enabled server integration. The destination after the first colon in an event name is provider-specific.
| Provider | OSS Conductor | Orkes |
|---|---|---|
| Conductor internal queue | Yes | — |
| Kafka | Yes | Yes |
| Amazon SQS | Yes | Yes |
| NATS | Yes | Yes |
| NATS JetStream | Yes | — |
| NATS Streaming | Yes | — |
| AMQP queue / exchange | Yes | Yes (including RabbitMQ) |
| Azure Service Bus | — | Yes |
| Google Cloud Pub/Sub | — | Yes |
| IBM MQ | — | Yes |
Operate the whole path
Monitor broker queue depth (event_queue_depth), message processing (event_queue_messages_processed, event_queue_messages_handled, and event_queue_messages_error), and handler actions (event_execution_success and event_execution_error). Then check the resulting workflow or task: broker acknowledgement alone does not prove the downstream action reached its intended state.
Next steps
- Publish events — send workflow data to a broker.
- Consume and route events — start or advance workflows from incoming messages.
- Incoming webhooks — accept verified HTTP callbacks.
- Send signals — advance an execution that is waiting.
- Workflow status events — notify external systems as executions change state.