Process Editor
The Process Editor is the primary means to create BPMN diagrams. It allows you to visually model them using simple drag-and-drop commands.
User Interface
The Process Editor user interface is roughly divided into four areas:
-
The menu bar on top, just below the navigation bar.
-
The palette on the left side.
-
The canvas in the middle.
-
The attribute bar on the right side.
Each area is described in detail in the following sections.
Menu Bar
The menu bar offers a number of actions, some of them only affecting the currently opened model while others have a more global impact.
| Group | Icon | Description |
|---|---|---|
| Save | Saves the currently opened model. | |
| Saves all opened models. | ||
| Validate | Validates the currently opened model. | |
| Edit | Copy the selected element. | |
| Pastes the contents of the clipboard. | ||
| Cuts the currently selected element. | ||
| Protocol | Undoes the previous action. | |
| Redoes the most current action. | ||
| Layout | Activates spacer tool. | |
| Locking | Locks the current model, see model locking | |
| Unlocks the current model to allow all user to get the lock. | ||
| Model | Opens the Data Model Viewer. | |
| Configure data contracts with data dictionaries. | ||
| Opens the Revision Editor, see model versioning. | ||
| Searches for an attribute value within the currently opened model. | ||
| Export | Exports the currently opened model in the saved state. | |
| Exports the currently opened model in the saved state as a picture. | ||
| Publish | Publish an app, see publishing apps. |
Drawing Area
To create your BPMN diagrams, you can use simple drag-and-drop commands. To do so, select an element in the palette on the left side and drag it to the drawing area. The element then becomes part of your model.
If you click anywhere in the drawing area, you can change certain attributes in the attribute panel on the right side. If you click on an element, you can change its attributes. If you click outside of an element (in the "space between"), you can change the attributes of the model itself, for instance the author, the version etc.
If you click on an element, a small popup appears on the top-right side. Here, you gain access to a number of often used elements which are directly linked to the currently selected element.
For instance, when you want to connect two tasks to another one, drag the hover over the Edge Drag symbol and drag it to another task. If you want to create a new User Task connected to the current task, do the same with the User Task symbol.
Revisions
The revision functionality of Flowable Design allows you to compare different versions of a model in a visual way. It also offers a way to revert a model to an earlier version of the model.
To compare revisions of your currently opened model, click the button where you are presented with the following screen:
On either side you find one version/revision of the model. The change revisions for the comparison select the required version in the drop down to the right side of each version’s header pane.
New elements are surrounded by a green border, changed elements by a yellow border and deleted elements by a red border. If you hover over an element where you have changed any attribute value, the changes are displayed. Hovering over a new or a deleted element shows all the attributes of that element.
If you wish you to revert to an earlier version of your model, you can do so by
pressing the button labeled Revert to this version.
Publishing Apps
When you are ready to publish your models, you can press the button. This action opens a dialog where you can select the app which you wish to publish.
Once you press the Publish button, the application is published.
Please note that this is
independent of the currently opened model. You still have to add all models
you wish to deploy with the app in the app editor.
More information about this topic can be found in the
Publishing Editor section.
What is BPMN?
The Business Process Model and Notation (BPMN) is a standard notation and formal specification of the Object Management Group for representing processes. It can be used to document processes in a concise way similar to a flowchart. BPMN is targeted at participants and other stakeholders in a business process to gain understanding through an easy-to-understand visual representation of steps. It provides a standard, common language for all stakeholders, whether technical or non-technical: business analysts, process participants, managers and technical developers, as well as external teams and consultants. Ideally, it bridges the gap between process intention and implementation by providing sufficient detail and clarity into the sequence of business activities.
In addition, BPMN in its current version was designed with automatic execution in mind. This means that a business process can be stored as a file and can then be used to automatize business processes using a so called BPMN engine such as Flowable.
Purpose of BPMN
BPMN is targeted at participants and other stakeholders in a business process to gain understanding through an easy-to-understand visual representation of the steps.
BPMN improves efficiency to gain competitive advantage.
BPMN Elements
The elements used for BPMN can be grouped into the following four categories:
-
Flow objects: events, activities, gateways
-
Connecting objects: sequence flows, message flows, associations
-
Artifacts: data object, group, annotation
All elements in BPMN have an ID and a name. While the ID must be unique, the name can be freely chosen. By default, both attributes are determined by the type of the element. The name of an element is its label and serves as a description of what the element does. In the case of activities, it should show what the activity does. The name of an event, on the other hand, should describe which event triggers the event.
It is possible to internationalize the name of elements. To do so, click on the language label next to the attribute which looks like this:
If you selected more than one language, each label can be translated into the other languages as well. The translation is entered into the "General" section of an element’s attribute.
Processes
The Process editor’s purpose is to model BPMN processes. Just like the elements which make up a process, the process itself has a number of attributes which can be set.
The following table gives an overview of all process attributes.
Process Attributes
| Group | Attribute | Description |
|---|---|---|
General | Model Key | The unique identifier of the process. |
Name | The name of the process. | |
Documentation | A description and additional information about the process. | |
Creation date | The date and time the process was originally created (read-only). | |
Modification date | The date and time the process model was last modified (read-only). | |
Security policy | The security policy associated with the process. | |
Folder path for uploaded content items | The folder path where uploaded content items for this process are uploaded. | |
Is executable | Determines whether or not the process is executable or not. Non-executable processes serve documentation purposes only and cannot be started. | |
Assignment | Owner | An owner for instances created for this process definition. |
Assignee | An assignee for instances created for this process definition. | |
Potential starter user | A single user who can potentially start the process. | |
Potential starter group | A group whose users can potentially start the process. | |
Participant users | Users that can participate in the process. | |
Participant groups | Groups of users who can participate in the process. | |
Watcher users | Users that have watcher access in the process. | |
Watcher groups | Groups of users who have watcher access in the process. | |
Details | Category | Category (target namespace) of the process model. This allows for the grouping of models. |
History level | How much historical information is stored for the process: None, Instance, Task, Activity, Audit or Full. | |
Execution listeners | Active execution listeners of the process. This lets you react to the following events:
| |
Data objects | Definition of data objects, a kind of meta information, available in the process. | |
Event listeners | Event listeners of this process which can react to many different events. See Events for more details. | |
Signal definitions | Definition of all signals used in this process. | |
Message definitions | Definition of all messages used in this process. | |
Eager fetching | Enables eager execution fetching of the process definition. | |
Initiator | The variable that holds the user that is used as the default user who initiates the process. | |
Version | The current version of the process. | |
Author | The author of the process (for documentation purposes). | |
Visual | Shape label expression | Replaces the label of all activities with the provided expression. For instance, |
Font size | Determines the font size of all labels. | |
Font weight | Determines whether or not labels are displayed in bold. | |
Font style | Determines whether or not the labels are displayed in italic. | |
Font color | Determines the font color of all labels. |
Subprocesses
A Sub-Process is a BPMN activity where the details have been completely defined inside a parent process (that’s why it’s often called an embedded Sub-Process).
Sub-Processes have two major use cases:
Using a Sub-Process does have some constraints:
Using a "Collapsed subprocess" over a “Call activity”?
BPMN 2.0 makes a distinction between a regular sub-process, often also called embedded sub-process, and the call activity, which looks very similar. From a conceptual point of view, both will call a sub-process when the process execution arrives at the activity.
The difference is that the call activity references a process that is external to the process definition, whereas the sub-process is embedded within the original process definition. The main use case for the call activity is to have a reusable process definition that can be called from multiple other process definitions.
When the process execution arrives at the call activity, a new execution is created that is a sub-execution of the execution that arrived at the call activity. This sub-execution is then used to execute the sub-process, potentially creating parallel child executions, as within a regular process. The super-execution waits until the sub-process has completely ended, and continues with the original process afterwards.
What is the difference between a "Subprocess" and an "Ad-hoc subprocess"?
In BPMN, an ad-hoc subprocess is one which has no sequence: the order in which the constituent tasks are performed is unknown or unspecified.
An ad-hoc sub process by default can execute multiple enabled activities at the same time. This is defined with the ordering attribute in the BPMN XML definition. This means that if you have a Adhoc subprocess with 2 tasks in it, you could execute Task 2, while also having Task 1 active at the same time.
Activities
Activities are the elements that actually do something in a process. There are three types of activities:
-
Task: The smallest unit of work in a process, for instance the prompt to fill out a form or a call to an external web service.
-
Call Activity: Executes another, previously defined process which is useful when a model becomes too large or when the same sequence of steps is required in different locations.
-
Sub-process: Allows to model a process within a process which is useful when working with loops, transactions and compensation.
Tasks
Tasks are the most common type of activity. In essence, tasks are the elements that do something in a process. There are a number of predefined tasks:
-
Flowable Work Activities
Gateways
Gateways are used to control how the Process flows (how Tokens flow) through Sequence Flows as they converge and diverge within a Process. If the flow does not need to be controlled, then a Gateway is not needed. The term “gateway” implies that there is a gating mechanism that either allows or disallows passage through the Gateway; that is, as tokens arrive at a Gateway, they can be merged together on input and/or split apart on output as the Gateway mechanisms are invoked.
— BPMN 2.0.2 Standard, 10.6, Gateways
Gateways are used to control the flow of a process. While the standard also allows branching without the use of gateways, using gateways greatly improves the understandability of a process model.
In Flowable, the following gateway types are supported:
Events
An Event is something that "happens" during the course of a Process. These Events affect the flow of the Process and usually have a cause or an impact and in general require or allow for a reaction. The term "event" is general enough to cover many things in a Process. The start of an Activity, the end of an Activity, the change of state of a document, a Message that arrives, etc., all could be considered Events.
— BPMN 2.0.2 Standard, 10.5, Events
In Flowable, events are triggers which either start, modify or complete a process. Events are represented as circles containing other symbols based on event type. There are three types of events: Start Events, End Events and Intermediate Events.
-
Start Events indicate where a process starts.
-
End Events indicate where a path of a process ends.
-
Intermediate Events indicate that something happens between start and end of a process.
For a process model to be executable, it must always contain at least one start event and one end event. Intermediate events can be placed if required. A simple example containing all three types of incoming could be the following process:
The process starts with a None Start Event followed by two activities. Then, the Intermediate Timer Event waits for an hour. After that, a final activity is being executed and the process ends with a None End Event.
As you can see, the Start Event can only have an outgoing sequence flow. The intermediate event has both, an incoming and and outgoing sequence flow and the end event only has an incoming sequence flow.
Additionally, every event is either throwing or catching. A catching event waits for something to happen. A throwing event allows another part of your process (or a new process) to proceed or to start. Every Start Event is a catching event because it waits for something to happen. Every End Event is a throwing event.
Finally, there are Boundary Events which are attached to tasks, sub-process, or a call activities. They are waiting for an event to happen while that activity is active. If the event occurs, the process execution follows the outgoing sequence of that boundary event. The following process shows how a boundary event could be used:
The process starts with a User Task, prompting a user to enter some data. Attached to this task, a Boundary Timer Event is starting a count down of one day, once the task has been activated. If the User Task has not been completed after a day, the execution continues to the Mail Task. After the Mail Task, there is an End Event. This does not mean that the process is completed! Instead, the task remains open until the user completes it. If you want to achieve this behavior, you must place an interrupting event.
Most BPMN Boundary Events can be both, interrupting or non-interrupting.
Interrupting means that the activity is completed and the flow continues
down the event’s sequence flow. In Flowable, the attribute Cancel activity
determines whether or not an event is interrupting.
The following example illustrates an example where an interrupting event makes sense:
This process is triggered by an incoming message. Then, the user has one hour to enter the activation code. If she fails to do so, the code is invalidated and the process is completed. Unlike in the example before, the circle of this event is dotted, indicating that the event is interrupting.
List of all Supported Event Types in Flowable
| Name | Start | Intermediate Catching | Intermediate Throwing | Boundary | End |
|---|---|---|---|---|---|
|
|
| |||
|
|
| |||
|
|
| |||
|
|
| |||
|
| ||||
| |||||
|
|
|
| ||
|
None Events
| Icon | Name | Description |
|---|---|---|
 | Event Start | Untyped start event is also called the None Start Event. The Start event is the most common type of event. Processes that start with such an event are created without any pre-conditions. It is common to use this event when a human starts a process through a graphical user interface. |
 | Event Throwing | This event marks the occurrence of a particular business event. Process execution is not delayed. In combination with execution listeners, this type of event can, for instance, serve as points to capture KPIs or other metrics. |
 | Event End | The untyped end event typically marks the typical end of a process. |
Message Event
| Icon | Name | Description |
|---|---|---|
 | Message Start Event | A process instance is started on receipt of a message. The reception of messages must occur in the back end. |
 | Message Catching Boundary Event | This event reacts on the arrival of a message. |
 | Message Intermediate Boundary Event | This event reacts on the arrival of a message. |
Timer Event
| Icon | Name | Description |
|---|---|---|
 | Timer Start Event | A process instance is started on cyclic timer events, at points in time, after time spans or after timeouts. |
 | Timer Catching Boundary Event | Process execution is delayed until a certain point in time is reached or a particular duration is over. |
 | Timer Intermediate Boundary Event | Process execution is delayed until a certain point in time is reached or a particular duration is over. |
Error Event
| Icon | Name | Description |
|---|---|---|
 | Error Start Event" /> | Catches named errors. This event is only used inside of a event sub-process. |
 | Error Intermediate Boundary Event | Catches a named error, which is thrown by an inner scope (for example, a sub-process). This event must be attached to the boundary of an activity. |
 | Error End Event | The process ends in an error state. As a result a named error is thrown. |
Cancel Event
| Icon | Name | Description |
|---|---|---|
 | Cancel Intermediate Boundary Event | Reacts on a transaction, which was canceled inside an inner scope (for example, a sub-process). This event needs to be attached to the boundary of an activity. |
 | Cancel End Event | Triggers the cancellation of a transaction. |
Compensation Event
| Icon | Name | Description |
|---|---|---|
 | Compensation Intermediate Boundary Event | Compensation handling in case of partially failed operations. This event needs to be attached to the boundary of an activity. |
Signal Event
| Icon | Name | Description |
|---|---|---|
 | Signal Start Event | A process instance is started based on signalling across different processes. A single thrown signal can be caught multiple times by different catching signal events. |
 | Signal Catching Boundary Event | Process execution is delayed until a particular signal is received. Signalling can happen across different processes. |
 | Signal Intermediate Boundary Event | Process execution is delayed until a particular signal is received. Signalling can happen across different processes. |
 | Signal Intermediate Throwing Event | The throwing signal event fires a signal. Afterwards it continues the process execution. Signals can be thrown either from the back end or using the Signal throwing intermediate event. One single thrown signal can be caught multiple times by different catching signal events. |
Terminate Event
| Icon | Name | Description |
|---|---|---|
 | Terminate End Event | Triggers the immediate termination of a process instance. All steps still executing in parallel branches are terminated. |
Connection Objects
In the following sections, the different ways to connect together BPMN elements are described.
Sequence Flows
A Sequence Flow is used to show the order of Flow Elements in a Process or a Choreography. Each Sequence Flow has only one source and only one target. The source and target MUST be from the set of the following Flow Elements: Events (Start, Intermediate, and End), Activities (Task and Sub-Process; for Processes), Choreography Activities (Choreography Task and Sub-Choreography; for Choreographies), and Gateways.
— BPMN 2.0.2 Standard, 8.4.13, Sequence Flow
There are a number of ways to connect elements in BPMN. However, by far the most common one within executable business processes is the Sequence Flow.
A sequence flow is the connector between two elements of a process. After an element is visited during process execution, all outgoing sequence flows are followed. This means that the default nature of BPMN 2.0 is to be parallel: two outgoing sequence flows create two separate, parallel paths of execution.
A sequence flow can have a condition defined on it. When a BPMN 2.0 activity is left, the default behavior is to evaluate the conditions on the outgoing sequence flow. When a condition evaluates to true, that outgoing sequence flow is selected. When multiple sequence flow are selected that way, multiple executions are generated and the process is continued in a parallel way.
The above holds for BPMN 2.0 activities (and events), but not for gateways. Gateways handle sequence flow with conditions in specific ways, depending on the gateway type.
A condition defined on a gateway must be an expression and must always evaluate either to the boolean value true or false.
All BPMN 2.0 tasks and gateways can have a default sequence flow. This sequence flow is only selected as the outgoing sequence flow for that activity if and only if none of the other sequence flow could be selected. Conditions on a default sequence flow are always ignored.
Message Flows
A Message Flow is used to show the flow of Messages between two Participants that are prepared to send and receive them.
— BPMN 2.0.2 Standard, 9.4, Message Flow
Message Flows connect model the information flow between two entities represented as pools. Information between two pools can only be exchanged via message flows. A message flow can be attached to pools, activities or message events. The order of message exchanges can be specified by combining message flows and sequence flows.
Executable business processes usually do not make use of message flows since they are not considered when executing the process. Using them only serves documentation purposes.
Association
An Association is used to associate information and Artifacts with Flow Objects. Text and graphical non-Flow Objects can be associated with the Flow Objects and Flow. An Association is also used to show the Activity used for compensation.
— BPMN 2.0.2 Standard, 8.4.1, Association
Provides a way to connect a Data Objects to any other element in a BPMN diagram. They do not have any impact on the execution of the business process.
Pools and Lanes
Processes in BPMN models are often wrapped in a so-called pool which is further divided into lanes. The following sections describe how they can be used by the Flowable process engine.
Pool
A Pool is the graphical representation of a Participant in a Collaboration. A Participant can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer). A Pool MAY or MAY NOT reference a Process. A Pool is NOT REQUIRED to contain a Process, i.e., it can be a “black box.”
— BPMN 2.0.2 Standard, 9.3, Pool and Participant
A process does not necessarily need a pool to be executable. However, it can help to make the model clearer.
Pool Attributes
| Group | Attribute | Description |
|---|---|---|
Details | Is executable | Determines whether or not the process is executable. There can only ever be one executable business process per process model. |
Process identifier | Unique identifier of the process definition. | |
More | Is multi instance participant | Defines the multiplicity of a participant. |
Minimum | The minimum number of participants that must be involved in the collaboration. | |
Maximum | The maximum number of participants that must be involved in the collaboration. |
Lane
A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level, either vertically or horizontally.
— BPMN 2.0.2 Standard, 9.3.2, Lanes
Lanes are a good way to organize responsibilities in a process. Often, a pool defines a process or an organization and the lanes represent departments. BPMN elements such as Tasks, Gateways etc. are then modeled within the pool that most matches that organizational unit. While this has no effect on most tasks, User Tasks can benefit from it.
Artifacts
BPMN provides modelers with the capability of showing additional information about a Process that is not directly related to the Sequence Flows or Message Flows of the Process.
— BPMN 2.0.2 Standard, 8.4.1, Artifacts
Artifacts provide additional information that modelers add to bring a necessary level of detail to the diagram. Artifacts do not directly add any runtime behavior but serve to make the model clearer.
Annotation
Annotations are a mechanism for a modeler to provide additional information for the reader of a BPMN Diagram.
— BPMN 2.0.2 Standard, 8.4.1, Text Annotations
Data Object
Data Object elements MUST be contained within Process or SubProcess elements. Data Object elements are visually displayed on a Process diagram. Data Object References are a way to reuse Data Objects in the same diagram. They can specify different states of the same Data Object at different points in a Process.
— BPMN 2.0.2 Standard, 10.4.1, Data Objects
Group
Groups are often used to highlight certain sub clauses of a Diagram without adding additional constraints for performance, as a Sub-Process would. The highlighted (grouped) sub clause of the Diagram can be separated for reporting and analysis purposes. Groups do not affect the flow of the Process.
— BPMN 2.0.2 Standard, 8.4.1, Groups