Flows
A flow is a reusable block of logic that can be run from apps and other flows, exposed as an API Endpoint for external systems to call, or run automatically on a schedule. Flows encapsulate integrations and business logic once and let you reuse them across your apps and solutions without rebuilding them each time.
Flows can be thought of as functions at the solution level: they accept inputs, run logic, and return results. A single flow can be invoked from many places, so any change made to the flow propagates everywhere it is used.
A flow can be used to:
Encapsulate an integration with an external system, such as Brønnøysund, Google Drive, or Visma, so that the same integration logic is shared across your solution.
Implement shared business logic, such as a customer lookup or a status transition, that would otherwise be duplicated per app.
Receive requests from external systems, such as webhook callbacks or API calls, via API Endpoints.
Run unattended work on a schedule, such as a nightly data sync or a periodic cleanup.
Actions
A flow consists of one or more actions. An action is the unit of logic within a flow and works in much the same way as an action in an app or service - it is composed of action nodes that run in sequence.
Available action nodes
Flows currently support a subset of the platform's action nodes. Action nodes that are specific to apps, such as navigation nodes, are not available in flows.
The following action nodes are available in flows:
Data: Create Object, Create FIle Object, Create File Archive, Read Objects, Aggregate Data, Update Object, Delete Objects, Persist Objects, Set Selection, Sort Objects
Logic: While, Foreach, Next Iteration, Exit Loop, Exit Block, If, Switch, Block, Catch Exception, Throw Exception, End Execution, Sleep
Other: Run Action, Run Flow, Import Data, Generate Document, Web Request, Streaming Web Request, Send Email, Send SMS, Push Notification, Create Shortlink, Update Secret
User Accounts: Create User Account, Update User Account, Delete User Account
Debug: Log to Console
Inputs and outputs
An action inside a flow defines the data it accepts as inputs and the data it returns. Inputs are passed when the flow is called, and outputs are returned to the caller once the flow completes.
Inputs. Flow inputs are defined using action params. Action params on flows can be simple data types, enumerated types, object class references and schemas, the latter allowing structured data to be passed into a flow without first modelling it as an object class.
Outputs. A Flow returns output through two mechanisms:
Action Variables hold simple data types, schemas, or references to enumerated types or object classes.
Action data sources hold collections, similar to runtime-only data sources in apps, but scoped to the action rather than the app.
A flow can return any number of action variables and action data sources as part of its output. Once the flow completes, they are available to the calling action in the same way any action variable or data source would be.
File objects. File objects can be passed into and returned from a flow like any other object. When a flow is called from an app, a file object must be persisted before it crosses into or out of the flow. See Passing file objects on the Run Flow action node for details.
Triggers
A Flow action can be invoked in three ways. The available triggers for a Flow action are listed in the Triggers section at the top of the Flow action editor, and a Flow action can have any number of them.
Run Flow/Run Action. Flows are called from an action using the Run Flow or Run Action action node. Input values are mapped from the calling context — data sources, app variables, or function results — into the Flow's input parameters. Once the Flow completes, its output Action Data are available to subsequent action nodes in the calling action. Flows can be called from actions in apps and from actions in other Flows. Each calling action appears as a reference under the Flow action's Triggers section.
Schedules. A schedule runs the Flow action automatically on a cron expression. Schedules are configured per Flow action. See Schedules.
API Endpoints. A Flow action can be exposed as an HTTP endpoint that external systems can call. This allows a Flow to receive data from third-party integrations, respond to webhook callbacks, or serve as an API for external applications. See API Endpoints.
Flow variables
Inside a flow action, the Flow Data section of the data-binding dialog exposes a set of built-in variables, such as the active environment and the identity the flow runs as. The solution's resource files are also available. See Flow variables.
Concurrency
By default, a Flow action can run several times at once. Different triggers, or the same trigger firing again, can start overlapping runs. Selecting No concurrency on the Flow action's Action settings tab prevents this: while a run is in progress, any attempt to start the same action again fails instead of running.
The setting applies to the Flow action as a whole, across every trigger. Runs started by Run Flow, a schedule, or an API Endpoint all count as the same action running, and the check spans servers, so an action running on one server blocks a start on another.
A blocked run is not queued. It fails with the error FlowConcurrencyError: This Action is already running and has concurrency disabled, and is not retried or run after the current run finishes. A Flow action with No concurrency enabled also cannot call itself, whether directly or through another action that calls back into it.
Last updated
Was this helpful?