[object Object]

The Ultimate Guide to BPMN in Jira

What is BPMN?

The Business Process Modeling Notation (BPMN) is visual modeling language for business analysis applications and specifying enterprise process workflows, it is an open standard notation for graphical flowcharts that is used to define business process workflows. It is 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

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 examples for a Jira Workflow sub-processe, is a widely used 4-eye principle release step, which is much easier to design as a Jira workflow.

As rule of thumb

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

The following image represents a standard Jira workflow:

Created with Raphaël 2.1.0RESOLVEDOPENIN PROGRESSCLOSEDREOPENEDStart ProgressStop ProgressResolve IssueClose IssueResolve IssueClose IssueReopen IssueStart ProgressResolve IssueReopen IssueClose IssueClose IssueCreate Issue

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 to the Jira Workflow Designer at the Jira docs

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 business processes of an organization in a clear and consistent way. 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 and 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

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 analyst to stakeholder, can easily understand; aiding in business process analysis and business process improvements.

Any process described with BPMN is represented as a number of 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 by means of 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 by categories: 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 of a business process. A swimlane may contain flow objects that are performed by that lane (participant), except for black box that must have an empty body (we will talk about 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, process flows from left to right, while process in vertical swimlanes flow 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. 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 Customer will be modeled, making the Chef pool a blackbox.


Lanes

Lanes are 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 who 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 on modeling business process. 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 which 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.

Flower add Jira Project

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 details. For this reason, a sub-process usually contains another Business Process Model modeling its details.

Note that the selection of 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 customer's payment becomes important.

Events

Events are something that happen 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 the event trigger.

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

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 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 Intermediate event is responsible for driving business flow based on the event it specifies. 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 task which might be escalated to the project manager. 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 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.

StartIntermediateEnd
TypeNormalEvent
Sub
process
Event
Sub
process
non-
interrupt
CatchBoundaryBoundary
non-
interrupt
Throw
None
Start EventCircle
Message
Message Start EventCircle with mail symbol
Message Event SubprocessCircle with mail symbol
Message Event Subprocess Non-interruptDashed Circle with mail symbol
Message Event CatchDouble Circle with mail symbol
Message Event BoundaryDouble Circle with mail symbol
Message Event Boundary non-interruptDouble dashed Circle with mail symbol
Message Event ThrowDouble Circle with gray mail symbol
Message End EventThick Circle with gray mail symbol
Timer
Timer Start EventCircle with clock symbol
Timer Event SubprocessCircle with clock symbol
Timer Event Subprocess non-interruptDashed Circle with clock symbol
Timer Event CatchDouble Circle with clock symbol
Timer Event BoundaryDouble Circle with clock symbol
Timer Event Boundary non-interruptDouble Dashed Circle with clock symbol
Conditional
conditional start eventcircle with note symbol
conditional event subprocesscircle with note symbol
conditional event subprocess non-interruptdashed circle with note symbol
conditional catch eventdouble circle with note symbol
conditional boundary eventdouble circle with note symbol
conditional throw eventdouble dashed circle with note symbol
Link
link catch eventdouble circle with right arrow symbol
link throw eventdouble circle with gray right arrow symbol
Signal
signal start eventcircle with triangle symbol
signal event Subprocesscircle with triangle symbol
signal event Subprocess non-interruptdashed circle with triangle symbol
signal catch eventdouble circle with triangle symbol
signal boundary eventdouble circle with triangle symbol
signal boundary non-interrupt eventdouble dashed circle with triangle symbol
signal throw eventdouble circle with gray triangle symbol
signal end eventthick circle with gray triangle symbol
Error
error event subprocesscircle with lightning symbol
error boundary eventdouble circle with lightning symbol
error end eventthick circle with gray lightning symbol
Escalation
escalation event subprocesscircle with compass arrow symbol
escalation event subprocess non-interruptdashed circle with compass arrow symbol
escalation boundary eventdouble circle with compass arrow symbol
escalation boundary non-interrupt eventdouble dashed circle with compass arrow symbol
escalation throw eventdouble circle with gray compass arrow symbol
escalation end eventthick circle with gray compass arrow symbol
Termination
termination end eventthick circle with a solid gray circle
Compensation
compensation event subprocesscircle with rewind symbol
compensation boundary eventdouble circle with rewind symbol
compensation throw eventdouble circle with gray rewind symbol
compensation end eventthick circle with gray rewind symbol
Cancel
cancel boundary eventdouble circle with x symbol
cancel end eventthick circle with gray x symbol
Multiple
multiple start eventcircle with pentagon symbol
multiple event Subprocesscircle with pentagon symbol
multiple event Subprocess non-interruptdashed circle with pentagon symbol
multiple catch eventdouble circle with pentagon symbol
multiple boundary eventdouble circle with pentagon symbol
multiple boundary non-interrupt eventdouble dashed circle with pentagon symbol
multiple throw eventdouble circle with gray pentagon symbol
multiple end eventthick circle with gray pentagon symbol
Multiple Parallel
multiple parallel start eventcircle with plus symbol
multiple parallel event subprocesscircle with plus symbol
multiple parallel event subprocess non-interruptdashed circle with plus symbol
multiple parallel catch eventdouble circle with plus symbol
multiple parallel boundary eventdouble circle with plus symbol
multiple parallel boundary non-interrupt eventdouble dashed circle with plus symbol

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:

Data-Based Exclusive Gateway, also known as Exclusive Gateway is used to control process flow based on given process data. Each outgoing flow which is connected from gateway corresponds to a condition. The flow with 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 positive result will be traversed. Therefore, it may result in executing multiple flows if multiple conditions are satisfied.

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 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 followed flows will no longer be valid.

Sequence Flows

Sequence flow is used to connect flow elements. It is shown in 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 dotted line with an arrow head. Some examples of message that flows between pools: fax, telephone, email, letter, notice, 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, a successful execution of the Place Order task will produce data like purchase order, invoice, receipt, 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, completed, deleted, etc.

Groups

A group is a box with 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.