Flow
Audience:
Low-code EngineersSkill Prerequisites:
Actions,Tokens,Conditions
The Flow actions control how an action list runs. They group actions with their own error handling, run actions in the background, repeat actions, pause, and stop the list with or without an error. They don't do any work of their own. They decide when, how often and whether the actions inside them run.
Choosing an action
| Action | What it does | Use it to |
|---|---|---|
| Execute Actions | Runs a list of actions as one group, like a try/catch block, with its own On Error actions. | Log an error and show a friendly message when a service call fails, or put one condition on several actions. |
| Execute Actions Asynchronously | Starts a list of actions on a separate server thread and continues straight away. | Send notification emails or call a slow webhook without making the user wait. |
| Repeat | Runs a list of actions a fixed number of times, while a condition is true, or both. | Process data in batches, retry a call, or poll a service until a job finishes. |
| Wait | Pauses on the server for a set number of milliseconds. | Stay within an API's rate limit, or space out retries inside a loop. |
| Stop Execution | Stops all remaining actions without an error or a message. | Skip the rest of a submission when nothing has changed. |
| Throw Exception | Raises an error on purpose, with an Admin Message and a Friendly Message. | Stop when a business rule fails, or trigger the On Error actions of an enclosing action. |
To run actions once for each row of a list, use Execute Actions for each List Entry in the Lists Objects actions.
Tokens inside nested lists
The actions that hold a list of actions treat tokens differently:
- Execute Actions shares tokens with the actions around it. Tokens created inside are available afterwards.
- Execute Actions Asynchronously gives the background actions a copy of the tokens as they are when it runs. Nothing they change comes back, and the actions after it may run before the background actions finish.
- Repeat runs each repetition on a copy of the tokens. Its
Context Behaviordecides what's copied back after each repetition. With Don't save the iteration tokens, aWhile Conditionbased on a token changed in the loop never changes, so always setRepetitionsas a safety limit.
Handling errors
- Catch errors with Execute Actions. If an action in the list fails, the rest of the list is skipped and the
On Erroractions run with the[Exception],[ExceptionMessage]and related tokens. Then execution continues after Execute Actions. IfOn Erroris empty, the error is passed up. - Repeat handles errors differently. With
Continue on errorchecked, a failed repetition is logged and the loop moves on. Repeat'sOn Erroractions don't get the exception tokens. To capture error details, put an Execute Actions with its ownOn Errorinside the loop. - Background errors are only logged. If an action started by Execute Actions Asynchronously fails, the error is written to the application log and the user isn't told. Wrap the background actions in Execute Actions to handle the error, for example with Log Error.
- Raise your own errors with Throw Exception. Put the rule in the action's
Condition. If nothing catches the error, administrators and users in theLow-Code Engineerrole see the Admin Message and everyone else sees the Friendly Message. In workflows and APIs, the error fails the run and is returned to the caller.
Stopping and waiting
- Ending execution. Stop Execution, Display Message, Display Error Message and redirects end the whole action list, including the actions after any Execute Actions or Repeat that contains them. Nothing that already happened is undone. Use Stop Execution to stop quietly, a message action to tell the user why, and Throw Exception to report a failure.
- Waiting holds up the request. Wait and long Repeat loops keep the user's browser waiting and can run into request timeouts. Keep them short in forms and grids. For scheduled or long-running work, use Automation jobs. Background threads use the web server's resources, and their work is lost if the application restarts.
For logging errors, see the Logging actions. For actions that show messages and end execution, see Message.
Revised 10/02/2026