By leveraging message events, processes can pause their execution until the expected messages are received, enabling effective coordination and communication between various system components.
Boundary events
Boundary Events involve handling by first consuming the event occurrence. Message Catch Boundary Events, triggered by incoming messages, can be configured as either interrupting or non-interrupting.
Intermediate Events
- Intermediate events temporarily halt the process instance, awaiting a message.
Boundary Interrupting Events
- These events can only be triggered while the token is active within the parent node.
- Upon activation, the parent node concludes, and the token progresses based on the boundary flow.
Boundary Non-Interrupting Events
- Similar to interrupting events, non-interrupting events can only be triggered while the token is active in the parent node.
- Upon triggering, the parent node remains active, and a new token is generated to execute the boundary flow concurrently.
FlowX.AI works with the following message events nodes:
Message events correlation
Messages are not sent directly to process instances. Instead, message correlation is achieved through two properties that must match between the throw and catch events:
- Message name — configured via the “Correlate with catch/throwing events” dropdown, must be identical on both sides
- Correlation value — the runtime value extracted from the correlation key expression
A correlation key is an expression that resolves to a value at runtime. The engine extracts this value from the process instance and uses it to match throw and catch events. It is not the key name that matters, but the value it resolves to.For example, if two sibling subprocesses both use parentProcessInstanceId as their correlation key, the engine extracts the parent’s ID from each — since both share the same parent, the values match and the message is delivered.
Available correlation keys
The correlation key expression is evaluated against two sources, checked in order:
- Instance metadata — system properties automatically set by the engine:
- Process variables (
paramValues) — any custom variable stored in the process data model (e.g., orderId, applicationId, customer.ssn)
For communication between sibling subprocesses (subprocess → subprocess), use parentProcessInstanceId since both siblings share the same parent. Alternatively, pass a custom business key from the parent process to both subprocesses.
Timing requirement
The catch event must be in a waiting state (its token must have arrived on the node) before the throw event fires. If the throw executes before the catch is ready, the message will not be delivered and correlation will fail.When using async subprocesses, ensure the subprocess containing the catch event has enough time to reach the catch node before the throw event is triggered in another subprocess.
${kafka.topic.naming.prefix}.core.message.event.process${kafka.topic.naming.suffix}. The engine listens here and writes the response.
Message events configuration
attachedTo: a property that applies to boundary eventsmessageName: a unique name at the database level, must be the same for throw and catch events (configured via the “Correlate with” dropdown in the Designer)correlationKey: an expression that resolves to a value used to match the throw event with the correct catch event instancedata: allows defining the JSON message body mapping as output and input
Data example
Catch 
