Skip to main content
Version: 1.28 (Current)

Flow

Audience: Low-code Engineers

Skill 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​

ActionWhat it doesUse it to
Execute ActionsRuns 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 AsynchronouslyStarts 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.
RepeatRuns 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.
WaitPauses on the server for a set number of milliseconds.Stay within an API's rate limit, or space out retries inside a loop.
Stop ExecutionStops all remaining actions without an error or a message.Skip the rest of a submission when nothing has changed.
Throw ExceptionRaises 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 Behavior decides what's copied back after each repetition. With Don't save the iteration tokens, a While Condition based on a token changed in the loop never changes, so always set Repetitions as 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 Error actions run with the [Exception], [ExceptionMessage] and related tokens. Then execution continues after Execute Actions. If On Error is empty, the error is passed up.
  • Repeat handles errors differently. With Continue on error checked, a failed repetition is logged and the loop moves on. Repeat's On Error actions don't get the exception tokens. To capture error details, put an Execute Actions with its own On Error inside 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 the Low-Code Engineer role 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