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 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):
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.
A component is a presentational element in a page layout. Some of the components we see in the drawing tool include content (like presentation or list), input (like radio or toggles), data (like file upload or tables), and charts (like bar chart or line chart).
We can also create custom components, if we like.
We can use page containers to split a page layout into independent parts. We can add components to a page container.
We can style containers as Rows, Columns, Inline, Group, Flip, Chart.
We can also nest containers, if we like.
Content types define what kind of data a value/property can hold. Content types can be Boolean, Content, DateTime, List, Number, Object, Password, String, or Encrypted. A content type is not the same as type (which is a structure definition of an object, like an interface or a struct in programming).
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 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 or flow graph) 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 a collection of metadata, map elements, and group elements that define a process. The flow graph is a metadata/graph representation of how the flow is laid out while designing, including the co-ordinates of all the elements and the links between them. The flow diagram is a visual representation of the flow graph.
An alphanumeric string that is unique to a flow. A Flow ID is generated when a flow is first created.
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.
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.
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 previous snapshot of the flow.
We can access previous snapshots 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. It is good to keep in mind, we don’t version modeling data, only snapshot data with flow versions.
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.
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.
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 send a callback to a flow for it to take appropriate action.
We can execute script from within our flow, by using the macro element.
The default identity service 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.
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; 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.
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.
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:
A Boomi Flow player is the interface used to render flows. The default Boomi Flow player uses HTML5 and 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.
The drawing tool allows you to create custom implementations of the default Flow HTML5 player, which you can add your own custom styles to, and modify to your liking. By using the Flow API (or our SDKs), you can create a player in any language to render a flow on any interface of your choosing.
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.
We can use the ManyWho Runtime service for starting parallel flows, which are flows that are started in the background. The service gives you back a “state” type, which you can use to show information about each subflow inside the parent flow (like the Join URI).
Some of the other things you can do with the service include:
- Executing sub-flows as a message action
- Listening to flow states for UPDATE and DONE events
- Loading states, optionally querying on “External ID”
- 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.
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.
The state can be defined as the running instance of a flow that contains all the data.
States are running instances of a flow. The State ID provides the unique id of a state. The api/admin/1/states endpoint lists all the states in a tenant, along with their State IDs.
A subflow is a second flow a 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.
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.
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 a 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.
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.
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 the app we are building with Boomi Flow.
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.
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.