Flow – Quick concepts

Let’s familiarize ourselves with Flow concepts.


Access or authorization defines who has permission to run a flow. The options include – Anyone can run this flow, Any user that can login with the selected identity service can run the flow, Create restrictions for users and specific users. (Access is called authorization in the API).


Boomi Flow elements include actions, which are features that act on the state of the flow, or provide feedback to the user. Actions shown on the same line are parallel or simultaneously evaluated. Actions include operation, navigation override, message actions, vote, data actions (which include filters), listeners, and content actions (like feedback).


Abbreviation for application. At Boomi Flow, we convert business processes into flow diagrams, which get converted by the Flow engine into applications. A typical flow includes user roles, business rules, and routing based on the rules.


Abbreviation for Application Programming Interface. An API is a software library or protocol that facilitates interaction between different software or services. You can find the Boomi Flow API documentation here.


Assets are files we may want to include in our workflow; like images, videos, or presentations. These are static resources that could be images, presentations, spreadsheets, text files, code snippets, or brand identity kits (logo, custom graphics).

We can find more information on assets here.


Authentication is the process by which our user (or groups of users) are identified by an app. Flow apps typically use a username and password combination for authentication. We can also build public apps that do not require any authentication to run, by using the default Identity service that comes with our tenant.

Third-party services that support authentication include Salesforce and Box. If a service supports authentication, the Identity option will be checked under service features.


Person building a flow using the Boomi Flow application. We can add multiple builders to a tenant.

Business rules

Business rules in a Boomi Flow application are a representation of real-world business rules (or policies or logic). Business rules can be used to define different outcomes or actions based on conditions specified in the rule. Business rules can be implemented for user interface, data, routing, or validation.


When we are building an app with Boomi Flow, the canvas is where we build the flow. This is the canvas (the thingamajig inside the red border):


We can add comments when creating a flow or creating values, to add notes or reminders to ourselves. Comments are visible to all builders in a tenant, but is not displayed to users.


Boomi Flow has been certified ISO27001:2013 compliant. The Flow platform provides HIPAA compliance in encryption, disaster recovery, access controls, and auditing. Customers can leverage the Boomi Flow platform’s PCI-DSS compliance to reduce their own PCI compliance complexity.

The Boomi Flow platform has also been implemented using the HITRUST CSF.

Find more information on Boomi Flow’s security and compliance program here.


We can use page components to split a page layout into independent parts. Once created, components can be reused. (Components are similar to functions in programming.) Flow components are divided into Content, Input, Data, and Charts.

Content — Hidden | Presentation | List | Outcomes | Image

Input — Input | Radio | Checkbox | Toggle | Text | Rich Text | Combobox

Data — File Upload | Table | Files | Tiles

Charts — Bar | Line | Pie | Doughnut | Polar Area


A container is a presentational element in a page layout. We can add various components to a page container.

We can style containers as Rows, Columns, Inline, Group, Flip, Chart.

We can also nest containers, if we like.


The Boomi Flow debugger lets us observe run-time behavior of our flow, and track root faults, component errors, pre-commit state values, state values, and execution log. We can access debug options from the Run menu.

This is how debugging a flow looks like:


A decision is an element in the Boomi Flow drawing tool that allows us to route our flow via different execution paths depending on a set of conditions; for example if a value is equal to a specific text.


The delete element lets us delete an item (or multiple items) from an external source via a service.

Drawing tool

The Boomi Flow drawing tool is the drag-and-drop environment where we build our apps, manage tenants or users, create types, and so on. Clicking LOG IN logs us to the drawing tool, with the Flows tab open.


We build apps in Boomi Flow by adding different building blocks to a canvas, and combining the blocks; these blocks are called elements. There are four categories of elements we use – Map, Shared, Group, and Navigation.

Map elements are elements we can drag and drop to the canvas (for example, a step that shows users an app screen). Map elements form the core logic of our flows, and it’s how we connect the map elements together that make the application function. Map elements can be used to pre-send pages to a user, to execute decisions and logical operations, call external APIs as messages to third-party applications, and manipulate data by saving, loading or deleting. All flows must have at least one map element.

Flow uses eight map elements – 1.| Step 2.| Page 3.| Decision 4.| Operator 5.| Message 6.| Load 7.| Save and 8.| Delete.

Shared elements are elements that can be shared (for example, a value is shared across all flows in a tenant).

Group elements let us provide permission-based access to parts of our app. We have one group element – which is the swimlane.

Navigation elements let us add navigation to our app (similar to how a menu would work in a website), giving us the ability to handle non-linear processes.


A flow (also, flow diagram) is how we build our app in Boomi Flow. Once we have diagrammed our business process on the canvas, the Boomi Flow Engine converts it into a working app.

A flow is the most fundamental piece of the Flow platform. A flow represents all of the elements that will comprise our workflow application. It is the flow that brings it all together as an executable application for your end user.

This here is a flow diagram:

This flow diagram converts into this app, when published:

Flow ID

An alphanumeric string that is unique to a flow. A Flow ID is generated when a flow is first created.

Flow Version ID

The Flow Version ID stores an unique identifier generated by the Boomi Flow engine for each version of the flow. The ID has 36 characters, a combination of 32 lowercase alphanumeric characters and four hyphens; there are no spaces. We can find the Flow Version ID at the bottom of our Boomi Flow canvas.

Flow Run URL

The URL generated when we run a flow is the Flow Run URL. The URL includes the Flow ID, which remains constant throughout the lifecycle of a flow, and the Flow Version ID, which is updated every time a flow is edited. It also includes information about the player used to run the flow.

Flow versions

Boomi Flow includes a full versioning capability for flow edits. A new flow version gets created every time a flow is run or published. We can think of flow versions as a ‘release log’, that allows us to easily rollback to a previously ‘released’ version.

We can access previous versions of a flow, by clicking the Properties icon on the right-hand-side navigation.
We can find information on how to roll back to a previous flow version here.


We can decide who has permission to access the application we are building, by creating restrictions for specific users and groups of users. Any service that supports identity, lets us create groups.

Identity service

Boomi Flow applications need an identity service (like Salesforce or Box) that is used to authenticate access to a flow (with a username/password, token, etc.) and authorize access to parts of a flow (permissions for a swimlane, flow, etc.).

A Boomi Flow tenant comes with an identity Service, which we can use to build public apps or apps that do not need third-party authentication. We are asked to select a service while creating our flow.

Join URI

Each flow is able to automatically generate a link, which allows someone to invite collaborators or rejoin the specific flow at a later date. This is a system value called the $JoinUri. A join URI allows us to share the running instance of a flow with multiple users. After starting a flow the URL in the address bar will change to a join URI.


When we are creating a type, we need to create properties for that type. The kind literally specifies what kind of properties we are creating. Kind can be  Boolean, Content, Date/Time, List, Number, Object, Password, String, or Encrypted.


The loads element allows us to fetch data from an external source via a service into a value (either a single item or a list of items).


A Boomi Flow listener is used to listen to events on objects stored or managed by a service. When an event occurs (example, a record is updated) in the underlying application (say, Salesforce), the service can invoke a flow for it to take appropriate action.


We can execute script from within our flow, by using the macro element.

The macro can be used for calculations (X times Y), logic (If X greater than Y Then…), as well as data validation, like: (If (X == “”) then generate an alert that X can not be empty).

ManyWho Identity Service

A Boomi Flow tenant comes with a default identity service, which can be used to build public apps or apps that do not need third-party authentication.


Messages allow us to interact with systems outside of Boomi Flow via services. We can use the message element to send a text message using Twilio, for example.


Metadata is data about the data and elements in your flow. For example, if you have a step, its metadata will include the data it was created, the date it was modified, who created the element, etc.

Boomi Flow separates the metadata of a flow from its data, making it easy and simple to update or localize content.


Flow metrics provides us quantitative information about our tenant and flows. Right now, we can see the number of states created, service failures, and service requests.


The navigation element lets you link and group elements into a menu bar. You can link to any map element using the navigation, to create a menu.You can use the navigation element to build non-sequential workflows, where flow control passes from one element to another without waiting for a previous element to be executed. This is an example of navigation:


Operators allow us to manipulate values when a flow is running, by defining one or more operations. For example, we can set a date/time value, or assign an object’s property. Each operation can be given a specific Order value (from 0 to infinity); this number will determine the order in which the operations will be run. Operations with the same order execute simultaneously.

An operation can be used to change values in the state.

Operations are performed immediately on the state, and execute within the platform without any user involvement.


Outcomes connect elements in the canvas and show how a flow progresses. In our app, the outcomes get converted into buttons, that when clicked take the user to the next screen.

Some elements (like Load or Save, that handle backend database actions and are not visible in the front end), do not have any buttons that are visible in the app, but must still be connected using outcomes.

The first outcome in the flow is the outcome of the Start element, which connects an arrow from Start to the first element you place on the canvas. All your flows will have at least one outcome (connecting the Start element to another element in the canvas). This is an example of an outcome:

Subsequent elements can have multiple outcomes.

Page layout

A page layout in Boomi Flow lets us create and structure a page to show our users. A page layout is extremely extensible, and gives us a rich variety of options to structure and display rich content with.

This is a page layout:

We can see a preview of what this page layout will look like in the app:


Boomi Flow player is the interface used to render flows.Boomi Flow players use themes (think of them as skins) for the app. Flow ships with all of the Bootswatch themes as standard, as well as the Salesforce 1 theme. We can also create a new player, and customize the CSS code to our liking. This is a screen from an app running the Salesforce player:


We can create a picklist to let users select values from predefined lists — for example a picklist of countries where the user is from. In Boomi Flow, picklist is available as a custom type.


Running a flow lets us see how the app will be rendered in real life. We can run a flow by clicking the Play button on the right-hand-side navigation of the canvas.

We can also run a flow by clicking Run on any flow in the Flows tab.

In the Run dialog, we need to consider which UI we want your flow to run in. If we do not have a player installed, the flow runs in the default player that comes with Boomi Flow.

Runtime service

We can use the ManyWho Runtime service to create subflows and flow outs. Flow outs are part of the core platform.

The runtime service can be used with the flow out feature to get the state information (say, load the state you want to join) or flow information (say,load the flow you want to flow out to).

Some of the other things you can do with the service include:

  1. Executing sub-flows as a message action
  2. Listening to flow states for UPDATE and DONE events
  3. Loading sub-flow states, optionally querying on “External ID”
  4. Loading runtime flows, optionally querying on “Flow Name”.

The ManyWho Runtime service does not come pre-installed in the tenant.


When we click Publish, the flow which we have built and is in our canvas, is automatically translated into an app which can be shared or deployed. The version of the flow which we are publishing becomes the default version.

The Boomi Flow Engine also creates a snapshot of the flow, which becomes the default version of our app.

Publishing a flow generates a Flow URL, which we can share with others. If we subsequently edit or update the flow and publish it again, end-users will automatically access the updated version of the app via the Flow URL.


The save element lets us send data back to an external source via a service.


A flow snapshot lets us get the entire structure of a flow in a single document. This can be handy if we want to provide visualizations of our flow to end-users, or simply check differences between versions.

A flow snapshot image is slightly different from packaging, in that it contains all of the details of the flow; but in object form so it can be parsed. The snapshot image is not appropriate for distribution, as it can contain sensitive information, but is also “unprotected” in that the structure of the flow is completely open.

The snapshot is the package that is sent to the Flow platform runtime engine.

Social feed for collaboration 

Select Display a social feed if you want to add a comment box that talks to a service. (Currently works with Salesforce Chatter.)


The state can be defined as the running instance of a flow that contains all the data.

If you like, you can configure how often state data is deleted for an application you are building. You can also chose to never delete state data.


The Step element lets us display content to end-users of our apps. A Step can contain videos, images, tables, links, presentations, or code snippets. The Step gets converted into an app screen.


A subflow is a second flow your flow calls during runtime.


We can use the swimlane element to use different authentication strategies for some parts of the flow. For example, we can split the same process to take different lanes for different people, groups of people, or subprocesses. There may be an ’employee’ swimlane and a ‘manager’ swimlane perhaps, for an app that approves expenses submissions.

To use swimlanes, we configure the authorization strategy for the swimlane and drag elements inside it.


A subtenant is a new tenant under the same tenant account.

Subtenants do not have visibility into the content, flows, values, or service integrations of the tenant (and vice versa).

We can use different subtenants for different divisions of an organization. For example, separate subtenants for HR and Accounting. Subtenants can also help to organize our project, for example, we can logically separate out deployment environments into Development, Staging, and Production.

Subtenants do not come with the default Boomi Flow services. If we want to use them, we will need to add the service integrations.


A tag lets us inject runtime values into UI components. They are similar to attributes, except instead of a static constant we can reference a value that is in the flow.

Tags and values are independent from each other; when we create a tag it is essentially an ID and a name. When we add a reference to a tag, we point to the tag and the value.

The same tag can be referenced in different places with different values.


A tenant is an user of a software application that serves multiple other users as well. When we create a Boomi Flow account, we are assigned a tenant where all our flows, content, and the metadata related to our flows are saved.

Tenant ID

An alphanumeric string that is unique to each tenant. A Tenant ID is generated when a Boomi Flow account is first created.


A type is an object used to send data to and from a service. A type uses a predefined structure, e.g. an Account, Person or Message. We can use types to create representations of real world things we are likely to use in our app. A type can have properties.

User interface

The parts of the app with which our user interacts directly. This includes the look and feel, commands, and menus through which an user interacts with our app. We can customize the Boomi Flow user interface to run our apps anywhere, or look the way we want them to.


The person who uses or will use our app.


The voting functionality is based on the authorization context of the map element in a flow.

If the map element is running in a swimlane, then voting is based on users who are able to successfully authenticate in that swimlane. If the map element is running without a swimlane, voting is based on users who are able to successfully authenticate with the flow.

Voting is supported by steps and pages.


Values in Boomi Flow are similar to variables in the programming paradigm. They are containers that have a name, and contain data. This data can be numbers, text, dates, instances of a type (say, Type: Customer), or another value. We can find more information on values here.

Vendor assets

Vendor assets are third-party JavaScript libraries that are loaded independently of the UI framework (for performance reasons). These are dependencies that we sometimes version.

Check out the glossary for a definition of terms and key concepts that appear in the Boomi Flow website, drawing tool, technical documentation, blogs, and marketing communications.

If you need to take a closer look, click on the images to enlarge them. Have a question? Click the Help button on the bottom right-hand corner of this page to ask.