Building blocks
Let's go through the steps from the example BPMN process diagram and see what are the corresponding FlowX.AI steps.
Make sure you have a clear understanding of BPMN concepts before going further.

FlowX.AI process building blocks

While designing the FlowX.AI components, we've tried to keep them as close to their BPMN counterparts as possible.
At the core of the platform are the process definitions. These are the blueprint of the business process, made up of nodes which are linked by sequences.


The platforms supports a few types of nodes, each needing a different configuration in order to fulfill their purpose in the business flow.

Node values

Nodes can have certain values attached to them, these can be used to define some extra details. For example, the name of the topic that a message receive task is waiting on. They can be saved in the DB as key / value pairs.


The activity that a node has to handle is defined using an action. These can have various types, they can be used to specify the communication details for plugins or integrations, can be used to include business rules in a process and also to send various data to be displayed in the front-end applications.
The FlowX.AI platform handles the following types of actions:
  • Business Rule
  • Kafka Send Action
  • WebSocket Send action
  • Validate Field
  • Upload File
  • Start Subprocess
  • Append Params to Parent Process

Action rules

Business rules can be attached to a node by using actions with action rules on them. These can be specified using DMN rules, MVEL expressions or scripts written in Javascript, Kotlin or Groovy.
Each button on the user interface corresponds to a manual user action.
Actions can be:
  • Manual or automatic.
  • They can be set as optional or mandatory. If not all mandatory actions are performed on the process node, the flow will not advance.
  • Actions can also be marked as one-time or repeatable.
Some actions can be set to run immediately after another action is performed. In order to achieve this, we need to set the parentName field on the action to be used as a callback. The callback actions can be performed when a certain message is received by the Engine. In order for this to happen the callbacksForAction header needs to be set on the message. Callback actions can also be configured to run imediatelly after the parent action is run, by setting the autoRunChildren flag to true for the parent action.

Action params

Action params are used to set extra values for actions. The are stored as key / value pairs. For example we can set a topic to use for sending outgoing messages or the message format to be sent to the front-end.
The decision that needs to be defined on an exclusive gateway is defined using a node rule. Similar to action rules, these can be set using DMN or MVEL.

Template configs

The FlowX Designer lets you create dynamic layouts associated with a USER_TASK node via the node's template configs tab.
These are created in a tree like structure always starting with a root component like a STEPPER, STEP, FORM_GROUP or CUSTOM.
The platform offers a series of ready to use ui components which can be used to create rich web interfaces. These include common form elements like input, select, checkbox, radio or toggle, as well as other ui elements like image, text, anchor links, etc. Each of these component's properties can be configured further using the details tab available when clicking on a specific component. Design flexibility is possible by adding styles or css classes to each of the pre-defined components.
For use cases where completely custom components are necessary the platform supports this by exposing the CUSTOM template config type. These can be developed in isolation and referenced by the component's class name when adding a custom component.


A subprocess can be started by a process in order to perform a specific set of actions. It will communicate with the front-end apps using the same connection details as its parent process. Also, a specific action can be used in order to save data from the child process directly to the parent process.
Last modified 2mo ago