Node actions

Actions define the activities that a node handles. Actions have various types and specify communication details for plugins or integrations.

Why is it important?

Node actions allow you to incorporate business rules into a process, and send data to front-end apps.

The FlowX.AI platform supports the following types of node actions:

Business rule

Save Data

Kafka send

Send data to user interface

Upload file

Start subprocess

Append params to parent process

Start integration workflow

Start new project instance

You can only define and add actions on the following types of nodes: send message task, task and user task.

Actions fall into two categories:

• Business rules
• User interactions

Business rules

Actions use action rules such as MVEL expressions or scripts in JavaScript, Python, or Groovy to attach business rules to a node.

Business rule action

Supported scripts

For more information about supported scripting languages, see Supported scripts.

Action edit

When configuring an action, the Action Edit panel provides three main configuration sections:

Trigger

This section defines how and when you can execute the action:

• Manual: Requires manual triggering through the REST API, typically by a user interaction in the interface (for example, clicking a button). When turned off, the action runs automatically.
• Repeatable: When enabled, you can trigger the action multiple times. When turned off, you can execute the action only once.

Manual actions can be either mandatory or optional. Automatic actions are always considered mandatory.

Execution

This section controls the action’s execution behavior:

• Optional: When enabled, the action is optional and the flow can advance without executing it. When turned off (default), the action is mandatory.
• Autorun Children?: When enabled, all child actions marked as mandatory and automatic run immediately after the parent action completes. Default is off.

If all mandatory actions on a node are not executed, the flow (token) doesn’t advance.

Navigation

This section controls user navigation behavior:

• Allow back to this action: Returns the token to this action from a downstream node only if you trigger the action manually. When enabled, you have the following “Back in steps” configuration options available:
  • When returning to this action, reset process data: Restores the process state and data to how it was before the initial execution of this action. Default is off.
  • Copy the following objects from current state: Specifies process keys that retain their data as persisted before you navigate back to this action.

Action parameters

Action parameters store extra values as key/value pairs, such as topics for outgoing messages or message formats for the front-end.

Configuring actions

Beyond the basic trigger, execution, and navigation settings described in the preceding section, actions have additional characteristics:

Action order

When multiple actions exist on a single node, the system executes them in the order you define them.

Parent/child hierarchy

Actions can be organized in a parent/child hierarchy, allowing you to create dependent action chains. Child actions can be configured to:

• Run automatically after the parent completes (using Autorun Children?): When enabled, all child actions marked as mandatory and automatic run immediately after the parent action completes. Default is off.
• Execute as callbacks when responses are received from external systems

For more information on adding and managing actions, see the following section:

Adding an action to a node

Linking actions together

You can link actions together in two ways so that certain actions run immediately after others:

Certain actions can run immediately after another action by setting the parentName field on the action for callbacks. Callback actions are performed when the Engine receives a specific message, indicated by the callbacksForAction header in the message. To run actions immediately after the parent action, set the autoRunChildren flag to true for the parent action.

Child actions

A parent action has a flag autoRunChildren, set to false by default. When you set this flag to true, the child actions (the ones defined as mandatory and automatic) run immediately after the parent action completes execution.

Callback actions

You can mark child actions as callbacks to run after receiving a reply from an external system. Set these actions when defining the interaction with the external system (the Kafka send action).

For example, you can use a callback function to handle a user’s interaction with a web page, such as uploading a file. When the user performs the action, the callback function executes, allowing the web app to respond appropriately.

Example

Add callback actions in the Advanced configuration tab, in the header parameter callbacksForAction.

{"processInstanceId": ${processInstanceId}, "destinationId": "upload_file", "callbacksForAction": "upload_file"}

• callbacksForAction: The value of this key is a string that specifies a callback action associated with the upload_file destination ID. This is part of an event-driven system (Kafka send action) where the system calls this callback after the upload_file action completes.