Event triggers
An event trigger starts the workflow when a platform event fires — a product created, an order placed, an app installed. Integration Studio is a consumer of the event stream; the trigger is how you subscribe from a workflow instead of writing a listener.
Subject patterns
The trigger carries a subject matched against the event's topic. Topics are lowercase, dot-segmented — revenexx.console.app.installed — and the subject may be an exact topic or a pattern:
| Subject | Matches |
|---|---|
revenexx.products.created | Exactly that topic |
acme.crm.*.created | * stands for exactly one segment |
revenexx.console.> | A trailing > stands for the rest of the topic |
The two wildcards are not interchangeable. * consumes exactly one segment, so acme.crm.*.created matches acme.crm.contact.created but not acme.crm.contact.address.created. A trailing > consumes everything that remains, so revenexx.console.> matches every topic under revenexx.console, however deep. > is only meaningful at the end of a subject.
Prefer the narrowest subject that does the job. A workflow subscribed to revenexx.> is started by everything that happens on the tenant, which is a run per event and a bill for machinery you did not want.
Matching is strict on the tenant: an event only ever fires triggers belonging to the tenant it came from.
The envelope in the payload
The whole envelope is available to the workflow:
| Expression | Value |
|---|---|
${{ trigger.payload.data.<field> }} | The event's own payload |
${{ trigger.payload.topic }} | The topic that fired |
${{ trigger.payload.id }} | The event id |
${{ trigger.payload.tenant_id }} | The originating tenant |
${{ trigger.payload.metadata.<key> }} | Event metadata |
${{ trigger.payload.time }} | When it occurred, ISO 8601 |
Note that the event's own fields sit under data, not at the top of the payload. ${{ trigger.payload.data.id }} is the id of the thing that happened; ${{ trigger.payload.id }} is the id of the event that reported it. Reaching for the wrong one is the classic mistake here, and because an unresolved reference resolves to nothing rather than failing, it shows up as an empty field further downstream. Build the expression with the picker in the node's input panel.
A pattern subject means one workflow can serve several topics, so branch on ${{ trigger.payload.topic }} with a Switch node when the handling differs — see the node catalog.
Delivery and de-duplication
Event delivery is at-least-once, but the trigger de-duplicates on the event id before creating a run, so the same event arriving twice produces one run rather than two.
That is a stronger guarantee than a schedule gives you, and it is worth knowing where it stops: it de-duplicates deliveries of one event, not events describing one change. A system that updates the same product three times in a second emits three events with three ids, and you get three runs. If that matters, collapse them on your side — key the write on the entity rather than on the event.
Which topics exist
Which topics exist is defined by the platform and by the apps installed on your tenant, not by Integration Studio. See Events for the topic taxonomy, and Consuming events for when a workflow is the right consumer and when a direct subscription is.
The short version: reach for an event trigger when the reaction is an integration — push this change into another system — and for a direct subscription when the reaction is your own application logic.
Where to go next
- Events — the platform service behind the trigger, and the topics available.
- Triggers — what all four types share.
- Expressions — reading the envelope into a node's config.
- Failure handling — an event-driven flow fails unattended, so route the failure somewhere you will see it.