Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt

Use this file to discover all available pages before exploring further.

By leveraging message events, processes can pause their execution until the expected messages are received, enabling effective coordination and communication between various system components.

​
Intermediate events

TriggerDescriptionMarker
MessageA Message Intermediate Event serves to send or receive messages. A filled marker denotes a “throw” event, while an unfilled marker indicates a “catch” event. This either advances the process or alters the flow for exception handling. Identifying the Participant is done by connecting the Event to a Participant through a Message Flow.Throw Catch

​
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.
TriggerDescriptionMarker
MessageNon-interrupting Message Catch Event: The event can be triggered at any time while the associated task is being performed.Non-interrupting
TriggerDescriptionMarker
MessageInterrupting Message Catch Event: The event can be triggered at any time while the associated task is being performed, interrupting the task.Interrupting

​
Intermediate vs boundary

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 message subscriptions, which consist of the message name and the correlation key (also referred to as the correlation value).
A correlation key is a key that can have the same value across multiple instances, and it is used to match instances based on their shared value. It is not important what the attribute’s name is (even though we map based on this attribute), but rather the value itself when performing the matching between instances.For example, in an onboarding process for a user, you hold a unique personal identification number (SSN), and someone else needs a portion of your process, specifically the value of your input (SSN).
The communication works as follows: you receive a message on a Kafka topic - ${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 events
  • messageName: a unique name at the database level, should be the same for throw and catch events
  • correlationKey: a process variable used to uniquely identify the instance to which the message is sent
  • data: allows defining the JSON message body mapping as output and input

​
Data example

{
	"document":{
			"documentId": "${document.id}",
			"documentUrl": "${document.url}"
	}
}
Last modified on January 26, 2026