What is BPMN?

The Business Process Modeling Notation (BPMN) (opens in a new tab) is a visual modeling language for business analysis applications and specifying enterprise process workflows, it is an open standard notation for graphical flowcharts that are used to define business process workflows. It is a popular and intuitive graphic that can be easily understood by all business stakeholders, including business users, business analysts, software developers, and data architects.

BPMN modeling and automation is supported in Jira by Flower - Process & Workflow Automation (opens in a new tab)

It provides a number of benefits for organizations, including:

• Improved communication: BPMN diagrams provide a visual representation of business processes, which can help to improve communication between stakeholders by providing a shared understanding of how processes work.
• Better process documentation: BPMN diagrams provide a clear and detailed record of business processes, which can be useful for documentation and compliance purposes.
• Enhanced process analysis: BPMN diagrams can be used to analyze and optimize business processes, helping organizations to identify bottlenecks, inefficiencies, and areas for improvement.
• Business Process Automation in Jira is supported by Flower - Process & Workflow Automation (opens in a new tab)

Are there limitations of BPMN in Jira?

Despite these benefits, there are a few limitations to consider when using BPMN:

• Complexity: BPMN diagrams can become complex and difficult to understand when representing large and complex business processes. Flower Workflow Automation reduces complexity, when it comes to Business Process Automation.
• Limited support for non-process activities: BPMN is primarily designed for modeling business processes, and it may not be well-suited for modeling other types of activities, such as decision-making or data manipulation.
• Limited support for dynamic processes: BPMN is designed to model static, predictable processes, and it may not be well-suited for modeling dynamic or unpredictable processes. You can consider dynamic processes as projects. Jira Work Management is the perfect tool to manage dynamic projects.

BPMN vs Jira Workflow

A Jira workflow is a set of statuses and transitions that an issue moves through during its lifecycle. It describes how the status will change serially for one single Jira issue, while BPMN describes multiple activities in serial or parallel order. When designing a Flower BPMN model you can consider the Jira Workflow as a sub-process; After resolving the Jira sub-process, the succession activity of your BPMN model becomes active.

A good example of a Jira Workflow sub-process is a widely used 4-eye principle release step, which is much easier to design as a Jira workflow.

As a rule of thumb

• Use Jira workflow for small workflows, which focus on status transitions in the context of only one Jira issue, project, or department;
• Use Flower BPM models to design bigger pictures, which might span multiple projects and departments.

Learn more about the differences between Jira Workflow and the stratigic view in a Business Process.

The following image represents a standard Jira workflow:

There are four basic building blocks for a Jira workflow – statuses, transitions, assignees, and resolutions.

Statuses

An Issue can only have one status at a time. It might be something like “In Progress” or “Complete”. However, when looking at new statuses, it’s worth considering whether a status represents an activity or a stage. For example, the status “Under Review” might represent a stage.

Transitions

A transition is a one-way or two-way connection that joins two statuses. Between the status “In Progress” and “Under Review” the transition might be “Submit for Review.” There may be conditions for who can make a transition and when. For example, only a project admin might be allowed to move an issue past the “Under Review” status.

The Issue Assignee

This represents who the issue is assigned to and who is responsible for it. It often changes between different statuses. When the task is done, the assignee's name can be removed. In BPMN Lanes are responsible to assign activities (Jira issues) to the responsible Jira user.

Resolution

The resolution is the final issue state – such as “Fixed,” “Complete” or “Won’t Fix.” If you ever want to reopen closed items, you’ll need to ensure that you have already resolved them. If you don’t, the now-active issue will confusingly appear to be complete and its name will have a line through it.

You can find more details about the Jira Workflow Designer at the Jira docs (opens in a new tab)

Business-IT-Alignment

BPMN is one of the most important components of successful Business-IT-Alignment. The following corporate roles deal with BPMN:

• Technical experts responsible for process implementation
• Business analysts who create and improve the processes
• Managers who monitor and control the processes

BPMN allows you to capture and document the business processes of an organization clearly and consistently. That ensures relevant stakeholders, such as process owners and business users are involved in the process. Thus, the team can respond to any issues identified in the processes more effectively. BPMN provides comprehensive yet rich notations that can easily be understood by both technical and non-technical stakeholders. Business process modeling provides important benefits to companies and organizations such as the ones listed below:

• An industry standard developed by the OMG consortium, a not-for-profit industry group
• Enables businesses to define and understand their procedures through Business Process Diagrams
• Provides a standard notation that is readily understandable by all business stakeholders
• Bridges the communication gap that frequently occurs between business process design and implementation
• Is simple to learn yet powerful enough to depict the potential complexities of a business process

What is the difference between Jira Workflow designer and a BPMN modeler?

Jira Workflow Designer is a tool that allows users to design and customize workflows within the Jira. It provides a visual interface for creating and modifying workflows, with a drag-and-drop interface for adding and arranging workflow elements.

On the other hand, a BPMN (Business Process Model and Notation) modeler is a tool for creating visual models of business processes using the BPMN standard. BPMN is a widely accepted standard for modeling business processes, and BPMN modelers allow users to design and document business processes using standardized symbols and notations.

In summary, Jira Workflow Designer is specifically designed for creating and customizing workflows within the Jira software, while BPMN modelers are more general-purpose tools for creating visual models of business processes using the BPMN standard.

BPMN Notation in Detail

Knowing how the business operates is the first and the most critical step of business process improvement.

Business Process Model and Notation (BPMN), provides a graphical representation of business workflows that anyone, from business analysts to stakeholders, can easily understand; aiding in business process analysis and business process improvements.

Any process described with BPMN is represented as several steps (activities) that are performed consequently or at the same time according to certain business rules. E.g. take a look at the "Budget Request" process.

In BPMN, the processes are described using diagrams with a series of graphic elements. Such visual presentation makes it easy for the users to understand the logic of a process.

BPMN has been primarily developed to design and read both simple and complex diagrams of business processes. For that, the BPMN standard classifies the graphic elements: As a result, the elements are easily recognized by the users who work with business process diagrams.

Let's dive into the different elements in detail:

BPMN Swimlanes

Swimlane objects (aka Swimlanes) in BPMN are rectangular boxes that represent participants in a business process. A swimlane may contain flow objects that are performed by that lane (participant), except for the black box that must have an empty body (we will talk about the black box later on in this tutorial).

Swimlanes may be arranged horizontally or vertically. They are semantically the same but just different in representation. For horizontal swimlanes, the process flows from left to right, while the process in vertical swimlanes flows from top to bottom. Examples of swimlanes include Customer, Account Department, Payment Gateway, and Development Team.

There are two kinds of swimlanes: Pools and Lanes.

Pools

Pools represent participants in a business process. It can be a specific entity (e.g. department) or a role (e.g. assistant manager, doctor, student, vendor).

Inside a pool, there are flow elements. They represent the works that the pool needs to perform under the process being modeled.

However, there is one kind of pool that has no content at all. It is known as the BlackBox pool. Blackbox pool is often used when modeling entities external to the business process. As it is external, its internal flow does not have any impact on the process being modeled, hence can be skipped, producing a BlackBox.

The following Business Process Model (business process diagram) gives you an example of a BlackBox pool. The customer is a blackbox. Since the process focuses on how the chef prepares a meal, what the customer does is none of the process' interest. The use of blackbox depends on the perspective the process takes. If you need to model the process of how a customer places an order, the flow of the customer will be modeled, making the Chef pool a blackbox.

Lanes

Lanes are a sub-partition of pools. For instance, when you have a pool Department, you may have Department Head and General Clerk as lanes. Same as pools, you can use lanes to represent specific entities or roles that are involved in the process. A lane also represents the Jira issue assignee. All activities within a lane will be assigned to the same Jira user.

Lanes may contain other lanes to form a nested structure when needed. However, BPMN helps you primarily with modeling business processes. Do not try to build nested lanes just for modeling the structure of your organization. If you want to model the organization structure, use the organization chart instead.

Activities

Activities are works that are performed within a business process. They are shown as rounded-rectangle, with names describing the works to perform.

There are two types of activities: Task and Sub-Process. When you want to model an atomic work that cannot be further broken down or makes no sense to do so, you use a task.

When it comes to workflow automation, each activity becomes a Jira issue. You can define which Jira project and issue type to be used by adding those values to the process model. If no project is specified, default values apply.

On the other hand, if you want to model a non-atomic, complex work that can be elaborated into smaller works, we use a sub-process. A sub-process can be broken down into another level of detail. For this reason, a sub-process usually contains another Business Process Model modeling its details.

Note that the selection of a task or sub-process is not just about how complex a work can be, but also about how detailed you need to know about the work. If you are a customer, you probably don't want to know how your payment is being processed. However, if you are the shop, how to process a customer's payment becomes important.

Adhoc

One marker available only for subprocesses is called ad-hoc. Recognize it by the tilde character "~" as shown in the diagram above: Use the ad-hoc subprocess to mark a segment in which the contained activities (tasks or subprocesses) can be:

• Executed in any order,
• Executed several times, or
• Skipped.

BPMN 2.0 specifies which symbols must, which may, and which are forbidden to occur within an ad-hoc subprocess. They are:

• Must: Activities
• May: Data objects, sequence flows, associations, groups, message flows, gateways, and intermediate events
• Forbidden: Start and end events, symbols for conversations and choreographies

Each party executing this subprocess decides what to do and when to do it. You could say that the "barely structured" nature of what happens inside this subprocess reduces the whole idea of process modeling to absurdity, because what happens and when are the things we most want to control. On the other hand, this is the reality of many processes, and you can't model them without representing their free-form nature. Common examples are when a process relies heavily on implicit knowledge or creativity, or when different people perform a process differently. You can use the ad hoc subprocess to indicate what might be an undesirable actual state. This could be a step towards a more standardized process.

Events

Events are something that happens and may have impacts on a business process. An event can be either external or internal. As long as they can influence the process being modeled, they should be modeled.

Events are shown as circles. In some cases, there are icons within the circles to represent the type of event trigger.

There are three types of events: Start Event, Intermediate Event, and End Event.

A trigger can be specified for each of them to indicate under what condition an event is being triggered.

Every process should have a Start event to show the beginning of the business process. It allows readers to locate in Business Process Model where the process begins. Moreover, the End event is used to indicate where a business process completes and the Intermediate event is responsible for driving business flow based on the event it specifies. An intermediate event can be attached to an activity for modeling an event that may happen DURING the execution of that activity and it may also be connected by a connecting object for modeling an event that may happen AFTER the execution of the flow element before. We will talk in more detail later on in this tutorial.

Take a look at the following example. It would give you some ideas on how events work. Basically, the diagram is saying we are doing some tasks which might be escalated to the project manager. The process ends when the task has been resolved or escalated.

We already saw Start events, Intermediate events, and End events. Those three event types are also catching and/or throwing events:

Catching events are events with a defined trigger. We consider that they take place once the trigger has been activated or fired. As an intellectual construct, it is relatively intricate, so we simplify by calling them Catching events. The point is that these events influence the course of the process and therefore must be modeled. Catching events may result in:

• The process starting
• The process or a process path continuing
• The task currently processed or the sub-process being canceled
• Another process path being used while a task or a sub-process executes

Throwing events are assumed by BPMN to trigger themselves instead of reacting to a trigger. You could say that they are active compared to passive Catching events. We call them Throwing events for short because the process triggers them. Throwing events can be:

• Triggered during the process
• Triggered at the end of the process.

You can also model attached Intermediate events with BPMN. These do not explicitly require waiting, but they do interrupt your activities, both tasks, and sub-processes (see task escalation example). Such Intermediate events are attached because you position them at the boundary of the activity you want to interrupt.

Gateways

Gateways are responsible for controlling how a business process flows. They are shown as diamond shapes. In a process, the work to do and the output may vary under different external or internal conditions. For example, a discount will only be offered to a VIP buyer but not to anyone else. Gateway is where conditions are evaluated and the decision is made.

Here are some typical types of gateways:

A data-Based Exclusive Gateway, also known as an Exclusive Gateway is used to control process flow based on given process data. Each outgoing flow that is connected from the gateway corresponds to a condition. The flow with the satisfied condition is traversed. Only one flow will be traversed.

Inclusive Gateway can be used to create parallel paths. The conditions of all outgoing flow are evaluated. All flows with a positive result will be traversed. Therefore, it may result in executing multiple flows if multiple conditions are satisfied.

A parallel Gateway is used to model the execution of parallel flows without the need of checking any conditions. In other words, all outgoing flows must be executed at the same time.

Event-Based Gateway is used to model alternative paths that are based on events.

For example, to wait for someone's reply, either Yes or No is needed to determine the path to traverse. The gateway is therefore followed by two connected intermediate events with message triggers, with one representing the Yes message and another one for No. When any ONE of the events is triggered, then the flow that follows that event will be taken. All the other events and their following flows will no longer be valid.

To automate BPMN gateways, you need to make decisions. You make decisions by launching one of the subsequent activities after the gateway. Depending on the gateway type (inclusive OR or exclusive XOR) you can select one or multiple successors. Learn more about how to automate gateways in Flower.

Sequence Flows

A Sequence flow is used to connect flow elements. It is shown in a solid line with an arrowhead. It shows the order of flow elements.

You can only use Sequence flow to connect flow elements within the same pool: Either within the same pool/lane or across lanes in the same pool. If you want to connect elements across pools, you cannot use Sequence Flow but Message Flow instead.

Message Flows

In BPMN, the communication between pools is achieved by the use of Message flows. A Message flow is used to show the flow of messages between pools or flow elements between pools. A message flow is shown in a dotted line with an arrowhead. Some examples of message that flows between pools: fax, telephone, email, letter, notice, and command.

You can only use sequence flow to connect flow elements within the same pool: either within the same pool/lane or across lanes in the same pool. If you want to connect elements across pools, you cannot use sequence flow but message flow instead.

Data

Very often, data is generated or consumed during the execution of a business process, either during or after the process is completed. For example, successful execution of the Place Order task will produce data like purchase orders, invoices, receipts, etc. In BPMN, data can be modeled by several types of 'data' objects such as data objects, data inputs, data outputs, and data stores. There is a well-defined way to manage the states of data, like instantiation, completion, deletion, etc.

Groups

A group is a box with a dotted line border, providing modelers a mechanism to group shapes by different categories.

Text Annotations

A text annotation can be used to add extra detail to flow objects in a Business Process Model. It does not affect the flow but gives details about objects within a flow. Also, use this label to add extra instructions for the Jira user

When it comes to workflow automation, text annotations become the description field in the related Jira issue.

What Workflow patterns can be used in Jira and BPMN?

Workflow patterns are common, reusable solutions to recurring problems in workflow design. Here are a few examples of workflow patterns:

• Sequence: A linear workflow in which tasks are performed in a specific order.
• Parallel Split: A workflow in which multiple tasks are performed concurrently.
• Exclusive Choice: A workflow in which one of several paths is chosen, based on a condition or decision.
• Simple Merge: A workflow in which two or more tasks are merged into a single task.
• Multiple Merge: A workflow in which multiple tasks are merged into a single task, but all tasks must be completed before the merge can occur.
• Structured Loop: A workflow in which a task or sequence of tasks is repeated a predetermined number of times.
• Multi-Instance: A workflow in which a task or sequence of tasks is performed for each item in a collection.
• Recursive: A workflow in which a task or sequence of tasks is repeated until a certain condition is met.
• Blocking: A workflow in which one task must be completed before the next task can begin.
• Non-Blocking: A workflow in which tasks can be performed concurrently, even if they are not dependent on each other.
• Cancelling: A workflow in which a task can be cancelled before it is completed.
• Escalation: A workflow in which a task is escalated to a higher level of authority if it is not completed within a certain timeframe.
• Event-Based Split: A workflow in which a task is split into multiple tasks based on an external event.
• Event-Based Merge: A workflow in which multiple tasks are merged into a single task based on an external event.
• Exclusive Choice with One Alternative: A workflow in which one of two paths is chosen, based on a condition or decision.
• Exclusive Choice with Multiple Alternatives: A workflow in which one of several paths is chosen, based on a condition or decision.
• Complex Merge: A workflow in which multiple tasks are merged into a single task, but only some of the tasks must be completed before the merge can occur.
• Structured Loop with a Condition: A workflow in which a task or sequence of tasks is repeated until a certain condition is met, at which point the loop is terminated.
• Multi-Instance with a Condition: A workflow in which a task or sequence of tasks is performed for each item in a collection, but the iteration is terminated when a certain condition is met.
• Recursive with a Condition: A workflow in which a task or sequence of tasks is repeated until a certain condition is met, at which point the recursion is terminated.

Automate complex Business Processes and Workflows with Simplicity

Mapping single Jira workflows won't necessarily go far enough. Flower Workflow Automation adds the strategic layer to your business process management.

Unlock the full power of Jira by aligning and streamlining your BPMN processes and workflows directly with your team: Every business process turns into an automated workflow by creating a Jira issue for each business process activity.