Process Modeling Best Practices
Follow BPMN best practices to design dynamic business processes.
Follow these BPMN best practices to develop business processes that not only showcase a stunning design, but also help increase the efficiency of your organization.
For each example, the Bad Practice tab displays by default. Click the adjacent Good Practice tab to view the best practice to follow. These practices cover the following design aspects of a business process:
- Why: Clearly define the purpose of a Process. If the Process is replacing an existing one, document the problems encountered in the current Process. This will ensure that the new Process being developed resolves all issues currently being faced.
- Who: Define the participants of your Process. This includes internal and external users and stakeholders.
- What: Document the intended outcome of the Process. Define the expected results and the targets to be achieved.
Use a descriptive name for a Process that concisely defines its purpose. Avoid using the name of your organization in the Process name, but instead highlight the business requirement the Process fulfills. When naming a child Process, use the parent Process's name to highlight the relationship.
An inconsistent direction of flow makes it harder to comprehend the Process model.
A clear left to right workflow makes it easy for a viewer to understand the Process model.
A Process using horizontal Sequence Flow elements and vertical Message Flow elements.
Every Process must have at least one clearly defined default path. This is the path that an instance of this Process follows when there are no errors or exceptions. In ProcessMaker, an instance is called a Request. After defining a default path, configure alternate paths for error handling.
A Process showing a clear default path and some alternate paths for error handling.
Instead of creating one large Process with many Tasks, simplify Process design by dividing the Process into sub processes. This action not only helps design more efficient Processes, but also streamlines error handling and maintenance procedures for these Processes.
As a best practice, use at least one Pool element in a Process model. Organize BPMN elements within this Pool element to indicate the default and alternative workflow paths. Each Pool element in a Process model constrains workflow for an incident of that Pool element, called a Request. Moreover, it provides a concise workspace for Process Designers to organize all Process elements.
Do not create a Process without at least one Pool element.
Use at least one Pool element in every Process.
Lane elements clarify the participants in a Process and provide a pictorial representation of how tasks are distributed amongst teams or personnel in your organization. Each Lane element indicates a role, actor, or participant within the Pool element.
A Process with well-defined lanes effectively explaining the design.
Do not leave a Lane element within a Pool element empty. If steps do not fit into a Lane element, remove that Lane from the Pool element.
Place every element clearly within a Lane element. Process elements should not be placed on Lane boundaries.
Do not place Process elements on Lane boundaries.
Every Process element must be clearly contained within the boundaries of its Lane.
- Use a verb to describe the work to be done and a noun to describe the object on which this work is being performed. For example,
Send Booking Details.
- If there is a need to use two verbs to describe the Task, consider splitting it into two Task elements.
- Use a verb to describe the action, a noun to describe the task or subject and a question mark to indicate a pending decision. For example,
- Use a brief interrogative statement to clarify the purpose of a Gateway. For example,
Is Start Date > 30 days?
A Process showing correctly named Gateways
Use a Gateway element whenever a business decision requirement occurs in the Process workflow.
Absence of Gateway elements makes the Process look disorganized.
Proper use of Gateway elements for branching makes the Process flow clear and organized.
Use one Gateway element to split the Request workflow and another to join it. Do not divert the workflow back to the splitting Gateway element. Moreover, use the same Gateway-type element to split and join. For example, when using a Parallel Gateway element to split workflow, use the same type of Gateway element to join it.
A Process using Parallel Gateways to split and join the Process Flow.
This Process is incomplete without an End Event element.
The presence of Start and End Event elements clearly define how/when the Process starts and ends.
When using more than one Start or End Event element in a Process, name them uniquely to clarify their purposes.
Using the same name for multiple Start Events creates confusion regarding their purposes.
Multiple Start Event elements in this Process have been labelled uniquely to depict their purposes.
Differentiate the use of Signal and Message type Events in all Event-type elements. Avoid using Signal-type events for design situations when the purpose is to send only a message in a workflow. As a best practice for this use case, use Message Events instead of Signal Events.
If using the Interrupting setting in a Boundary Event element, except Boundary Error Event elements, as a best practice use a "dummy" task ("Trash" in the example below) to store interrupted tasks caused by the Boundary Event element.
Use Text Annotation elements to provide a brief notation for general descriptions, Process logic, and exception handling. However, Text Annotation elements should be used in moderation and for brief information only. For detailed information about Process elements, use the features available through the Documentation package.