--- title: "Process Modeling Best Practices" slug: "process-modeling-best-practices-1" updated: 2026-08-10T22:05:38Z published: 2026-08-10T22:05:38Z canonical: "docs.processmaker.com/process-modeling-best-practices-1" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.processmaker.com/llms.txt > Use this file to discover all available pages before exploring further. # Process Modeling Best Practices Follow these BPMN best practices to [develop business processes](/v1/docs/process-modeler) that not only showcase a stunning design but also help increase the efficiency of your organization. These practices cover the following design aspects of a business process: - [BPMN 2.0 Modeling Guidelines for ProcessMaker](/v1/docs/process-modeling-best-practices#bpmn-20-modeling-guidelines-for-processmaker) - [Scope of the Process](/v1/docs/process-modeling-best-practices#scope-of-the-process) - [Process Map](/v1/docs/process-modeling-best-practices#process-map) - [Pools and Lanes](/v1/docs/process-modeling-best-practices#pools-and-lanes) - [Tasks](/v1/docs/process-modeling-best-practices#tasks) - [Gateways](/v1/docs/process-modeling-best-practices#gateways) - [Events](/v1/docs/process-modeling-best-practices#events) - [Process Documentation](/v1/docs/process-modeling-best-practices#process-documentation) --- ## BPMN 2.0 Modeling Guidelines for ProcessMaker ProcessMaker Platform follows Business Process Modeling Notation (BPMN) 2.0 specification. For more information about BPMN 2.0 see the [BPMN specification](https://www.omg.org/spec/BPMN/2.0/About-BPMN/). Designing Process models using the BPMN 2.0 specification involves several guidelines and best practices: - **Understand BPMN elements:** Familiarize yourself with the basic [BPMN elements](https://www.omg.org/spec/BPMN/2.0/About-BPMN/) such as [Tasks](/v1/docs/configure-task-objects), [Gateways](/v1/docs/configure-gateway-objects), [Events](/designer-modeler/model-your-process/event-elements/end-event-type-elements/add-and-configure-end-event-elements), and [Flow indicators](/designer-modeler/model-your-process/flow-indicator-elements), as well as more advanced constructs like [Sub Processes](/v1/docs/sub-process) and [Pools](/designer-modeler/model-your-process/add-and-configure-pool-and-lane-elements). - **Start with high-level views:** Begin by creating a high-level view of your [Process](/v1/docs/create-a-process). Use [Pools](/designer-modeler/model-your-process/add-and-configure-pool-and-lane-elements#add-a-pool-element-to-the-process-model) to represent different participants or departments involved in the Process, and [Lanes](/designer-modeler/model-your-process/add-and-configure-pool-and-lane-elements#add-a-lane-element-to-a-pool-element) to represent roles or responsibilities within each Pool. - **Use descriptive names:** Assign clear and descriptive names to [Tasks](/designer-modeler/model-your-process/task-elements), [Events](/designer-modeler/model-your-process/event-elements/end-event-type-elements/add-and-configure-end-event-elements), [Gateways](/designer-modeler/model-your-process/gateway-elements), and other [elements](/v1/docs/process-modeling-object-descriptions) to ensure the Process's intent is easily understood. - **Consistent styling:** Maintain a consistent style throughout your Process models, including shapes, colors, and annotations. - **Embrace Simplicity:** Keep your Process models as simple and straightforward as possible. Avoid unnecessary complexity that might confuse stakeholders. - **Flow direction:** Maintain the correct flow direction (left to right) for the Process. [Sequence Flows](/designer-modeler/model-your-process/flow-indicator-elements/the-quick-toolbar) should connect activities in a logical order. - **Message flow:** When modeling interactions between [Pools](/designer-modeler/model-your-process/add-and-configure-pool-and-lane-elements#add-a-pool-element-to-the-process-model), use [Message Flows](/designer-modeler/model-your-process/flow-indicator-elements/set-and-delete-message-flow-between-elements) to show the exchange of messages between participants. - **Use Gateways appropriately:** Choose the right type of Gateway ([Exclusive](/designer-modeler/model-your-process/gateway-elements/add-and-configure-exclusive-gateway-elements), [Inclusive](/designer-modeler/model-your-process/gateway-elements/add-and-configure-inclusive-gateway-elements), [Parallel](/designer-modeler/model-your-process/gateway-elements/add-and-configure-parallel-gateway-elements), or [Event-Based](/designer-modeler/model-your-process/gateway-elements/add-and-configure-event-based-gateway-elements)) based on the decision logic required in your Process. - **Parallel vs. Inclusive Gateways:** Understand the difference between [Parallel](/designer-modeler/model-your-process/gateway-elements/add-and-configure-parallel-gateway-elements) and [Inclusive](/designer-modeler/model-your-process/gateway-elements/add-and-configure-inclusive-gateway-elements) Gateways: use Parallel Gateways when multiple [Tasks](/designer-modeler/model-your-process/task-elements) should execute simultaneously, and use Inclusive Gateways when multiple Tasks could be triggered. - **Event-Based Gateways:** Use [Event-Based](/designer-modeler/model-your-process/gateway-elements/add-and-configure-event-based-gateway-elements) Gateways to represent conditional branching based on events rather than explicit decisions. - **Boundary events:** Apply [Boundary-type](/designer-modeler/model-your-process/event-elements/boundary-type-event-elements) events to [Tasks](/designer-modeler/model-your-process/task-elements) and other element types to represent interrupting events that affect that Task's execution. - **Sub Processes:** Use [Sub Processes](/designer-modeler/model-your-process/task-elements/add-and-configure-sub-process-elements) to encapsulate related activities, improving the overall clarity of the Process. Decide between embedded and reusable Sub Processes based on reusability. - **Artifacts:** Use artifacts like [Data Objects](/designer-modeler/model-your-process/annotation-elements/data-object-element) and [Annotations](/designer-modeler/model-your-process/annotation-elements) to provide additional information about the Process or its elements. - **Data Associations:** Clearly define [Data Associations](/designer-modeler/model-your-process/annotation-elements/data-association-flow-element) to show input/output relationships between [Tasks](/designer-modeler/model-your-process/task-elements) and [Data Objects](/designer-modeler/model-your-process/annotation-elements/data-object-element). - **Validation and testing:** Regularly [validate your Process](/designer-modeler/process-design/validate-bpmn-2.0-compliance) models to ensure they accurately represent the intended business logic. Test them with stakeholders to gather feedback. - **Collaboration:** Involve relevant stakeholders when designing Process models to ensure accuracy and alignment with business requirements. - **Version control:** Implement [version control](/designer-basics/view-the-list-of-processes/configure-process-version-history) mechanisms to track changes and iterations of your Process models. - **Documentation:** Create [documentation](/designer-basics/view-the-list-of-processes/view-documentation-of-a-process) that explains the purpose, logic, and flow of the Process model. This aids in understanding and maintaining the model. - **Training:** Provide training to individuals who will be working with or contributing to the Process models. This promotes consistent modeling practices. - **Continuous improvement:** Regularly review and refine your Process models based on feedback, changing requirements, and performance metrics. ## Scope of the Process Before beginning the actual development of a Process, clearly define the scope of business requirements using the following guidelines: - **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. ## Process Map ### Process Naming Conventions 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. | Bad Practice | Good Practice | | --- | --- | | MyBank Loan Process | Residential Loan Application | | The HR Process | Employee Onboarding | | Training Sub Process for HR | Employee Onboarding - Training Request | ### Consistent Direction of Workflow Maintain a consistent left-to-right direction for [Sequence Flow](/v1/docs/sequence-flow-element) elements and avoid crossing lines. This makes a Process map well-organized and easily readable for all stakeholders. **Bad Practice** An inconsistent direction of flow makes it harder to comprehend the Process model. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/image(87).png) **Good Practice** A clear left to right workflow makes it easy for a viewer to understand the Process model. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/7221c63a-b863-43be-a2a7-99d83ac1c074.png) ### Consistent Direction of Message Flow Elements While it is recommended to use horizontal (left to right) Sequence Flow elements, use vertical [Message Flow](/v1/docs/message-flow-element) elements to send messages across different [Pool](/v1/docs/process-modeling-best-practices#pools-and-lanes) elements. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/c375ff30-cbcb-4ce9-993d-cabce9142515.png) A Process using horizontal Sequence Flow elements and vertical Message Flow elements. ### Define a Default Workflow Path 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 Platform, an instance is called a Request. After defining a default path, configure alternate paths for error handling. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/593789da-d2b0-4b66-912c-4253327274e8.png) A Process showing a clear default path and some alternate paths for error handling. ### Use Descriptive Labels Use the [Text Annotation](/v1/docs/text-annotation-and-association-elements) elements to clearly label and define the purpose of different elements in a Process. ### Use Sub Processes 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. ## Pools and Lanes ### Use Pool Elements As a best practice, use at least one [Pool](/v1/docs/configure-pool-and-lane-objects) 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](/v1/docs/request-variable#overview). Moreover, it provides a concise workspace for Process designers to organize all Process elements. **Bad Practice** Do not create a Process without at least one Pool element. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/043c5f9e-adfd-4129-8b86-a886aad633a1.png) **Good Practice** Use at least one Pool element in every Process. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/a259c205-a399-4dee-a688-7cd640c52405.png) ### Use Lane Elements [Lane](/v1/docs/configure-pool-and-lane-objects#add-a-lane-element-to-a-pool-element) 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. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/45abc524-b898-46ee-9443-c152fef26edb.png) A Process with well-defined lanes effectively explaining the design. ### Avoid Empty Lanes 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. **Bad Practice** ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/e8b2a0d3-224b-479a-af1b-accee549bf13.png) **Good Practice** ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/61d160c3-6420-4296-bc26-c93119921f55.png) ### Element Placement in Lanes Place every element clearly within a Lane element. Process elements should not be placed on Lane boundaries. **Bad Practice** Do not place Process elements on Lane boundaries. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/44321ca1-c609-4c06-a902-f420f83cd84e.png) **Good Practice** Every Process element must be clearly contained within the boundaries of its Lane. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/f36b531d-94ca-4f6b-90d1-21cc428c3096.png) ## Tasks ### Task Naming Conventions Use a descriptive name for all Task-type elements which clearly defines the work being performed in these Tasks. Task-type elements include [Form Tasks](/v1/docs/form-task), [Manual Tasks](/v1/docs/manual-task), and [Script Tasks](/v1/docs/script-task). Follow these naming conventions: - 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, `Review Contract`, `Manager Approval` and `Send Booking Details`. - If there is a need to use two verbs to describe the Task, consider splitting it into two Task elements. ### Script Tasks #### Avoid Chaining Multiple Script Tasks Between Form Tasks It is common to place a [Script Task](/v1/docs/script-task) after a [Form Task](/v1/docs/form-task) to process the data a user just submitted. However, chaining **three, four, or more Script Tasks in sequence** between one Form Task and the next is not a good practice. Even though each Script Task runs one after another (not in parallel), their execution times add up. The user who submitted the form is left waiting for the entire chain to finish before the next Task becomes available to them, which directly hurts the end-user experience. ##### Why chained Script Tasks cause problems 1. **Cumulative delay before the next Task is available:** When a user submits a Form Task, the Request must complete every subsequent Script Task in the chain before the next Task (often another Form Task) is assigned and shown to a user. If each script takes even 1–3 seconds, four or five scripts in a row can add up to 10–20+ seconds — or much longer if any script calls an external system — of dead time between "I clicked submit" and "I see the next screen." 2. **No feedback during the wait:** Unlike a Form Task, a Script Task has no user interface. While the chain executes, the end user typically sees a spinner, a blank screen, or nothing at all, with no indication of progress or how long the wait will be. This reads as the application being slow or frozen, even when it is working correctly. 3. **Browser/session timeouts:** If the combined execution time of the chain is long enough, the user's browser session, an API gateway, or a load balancer timeout can be reached before the Request finishes routing to the next Task. This can produce errors that appear to the user as a failure, even though the Process is still completing correctly on the backend. 4. **One slow or failing script blocks the whole chain:** Because the scripts run sequentially, the chain is only as fast as its slowest link, and only as reliable as its least reliable link. A single Script Task in the middle of the chain that calls a slow external API, hits a timeout, or throws an error stalls or breaks the entire transition — even if the other three scripts are fast and reliable. 5. **Harder to diagnose which step is slow:** When a user reports "the system is slow" after submitting a form, a long chain of Script Tasks gives support and admins several possible culprits to isolate. Reviewing Request logs to find which specific script in the chain is responsible for the delay takes more time than it would with a single consolidated step. **Bad Practice** Placing several separate Script Tasks in sequence directly between two Form Tasks, so the end user must wait for the entire chain to complete before the workflow moves on. **Good Practice** - **Consolidate related logic into a single Script Task.** If multiple scripts are just performing related steps of the same operation (e.g., validate data, then format it, then calculate a value), combine that logic into one script rather than splitting it across several sequential Script Task elements. - **Move non-blocking work off the critical path.** If a step doesn't need to finish before the user can proceed (e.g., sending a notification, logging, writing to an audit table), don't put it in the user's transition path. Route it to a separate branch off a Parallel Gateway, or trigger it asynchronously (for example, via a [Watcher](/v1/docs/watchers) or an external job), so the user isn't stuck waiting on it. - **Use an Interstitial/summary Screen for necessary waits.** If real processing time is unavoidable, insert a Screen that tells the user something is happening, rather than leaving them on a blank or frozen page. - **Only chain scripts that must run sequentially.** If a script's input depends on the previous script's output, sequential order is required — but that's still a reason to combine them into a single script where possible, rather than several separate Script Task elements each carrying the overhead of its own executor invocation. - **Monitor and budget execution time** for any chain of scripts sitting directly in front of a Task assignment, and set a target maximum (e.g., under 2–3 seconds) for how long a user should wait between submitting one Task and being assigned the next. ### Web Entries Review the following best practices and restrictions when using tasks as a Web Entry. For more information, see [Web Entry Panel Settings](/v1/docs/form-task#web-entry-panel-settings). **Web Entry as Task** When sending files through a Script to an external database like ProcessMaker Intelligent Document Processing (IDP), the Request ID becomes essential. To ensure smooth functionality, it's advisable to follow these steps: 1. Create a [Start Event](/v1/docs/start-event) as a [Web Entry](/v1/docs/start-event#web-entry-panel-settings). 2. Assign a [Form-type](/v1/docs/screens#form-1) Screen to the Start Event element for uploading files. 3. Create a [Form Task](/v1/docs/form-task) element as a [Web Entry](/v1/docs/form-task#web-entry-panel-settings). 4. Assign a Form-type Screen to the Form Task for processing the uploaded files via a [Watcher](/v1/docs/watchers) to call the Request ID. 5. Copy the URL of the Form Task and paste it into the **Redirect URL** setting of the Start Event. The redirection will occur when all files have been uploaded. Trying to configure the Request ID within the same Form-type Screen used for uploading files in the Start Event element will not work correctly. This is because the Request ID is generated after the form is submitted. Therefore, it becomes available in the form opened using the Redirect URL setting. ## Gateways ### Gateway Naming Conventions Use descriptive names for [Gateway](/summer-2024/A7mdugENW7gZw1jmnrOv/designer-modeler/model-your-process/gateway-elements) elements to help clarify their purpose and their role in the business logic of a Process. Follow these naming conventions: - 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, `Application Approved?` and `Resend Notifications?` - Use a brief interrogative statement to clarify the purpose of a Gateway. For example, `Is Start Date > 30 days?` ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/49f680a8-b7e9-4dbf-ac32-4019015ef050.png) A Process showing correctly named Gateways ### Use Gateways for Business Decisions Use a Gateway element whenever a business decision requirement occurs in the Process workflow. **Bad Practice** Absence of Gateway elements makes the Process look disorganized. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/8bf62fdd-6245-4b4d-ab42-cba2b0d3f6ea.png) **Good Practice** Proper use of Gateway elements for branching makes the Process flow clear and organized. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/7f1091ad-b08a-4aaf-93ad-7999f28db656.png) ### Use Separate Gateways for Splitting and Joining Workflows 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](/v1/docs/parallel-gateway) element to split workflow, use the same type of Gateway element to join it. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/aacc56ae-108f-417f-8bc7-917e717097ea.png) A Process using Parallel Gateways to split and join the Process Flow. ## Events ### Use Start and End Events Every Process must have at least one [Start Event](/v1/docs/start-event) element and one [End Event](/v1/docs/end-event) element to clearly define the beginning and the culminating elements of a Process. **Bad Practice** This Process is incomplete without an End Event element. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/b434146e-82e3-4b52-8601-65f37c5b73fa.png) **Good Practice** The presence of Start and End Event elements clearly define how/when the Process starts and ends. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/7221c63a-b863-43be-a2a7-99d83ac1c074.png) ### Multiple Start and End Event Elements When using more than one Start or End Event element in a Process, name them uniquely to clarify their purposes. **Bad Practice** Using the same name for multiple Start Events creates confusion regarding their purposes. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/ed4a3de8-f8c2-463d-8d8c-e71f9c2d741a.png) **Good Practice** Multiple Start Event elements in this Process have been labelled uniquely to depict their purposes. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/6732e53e-5c9e-4b32-a067-98f28d5b3ae0.png) ### Signal and Message Events Differentiate the use of Signal and Message type Events in all Event-type elements. **Bad Practice** Avoid using Signal-type events for design situations when the purpose is to send only a message in a workflow. **Good Practice** As a best practice for this use case, use Message Events instead of Signal Events. ### End Events After Boundary Signal Events **Bad Practice** After adding a [Boundary Signal Event](/v1/docs/boundary-signal-event) element, using an [End Event](/v1/docs/end-event) closes the Request without sending the Signal. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/Boundary Signal Event - Bad Practice.png) **Good Practice** After adding a [Boundary Signal Event](/v1/docs/boundary-signal-event) element, as a best practice avoid using an [End Event](/v1/docs/end-event) because it closes the Request without sending the Signal. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/Boundary Signal Event - Best Practice.png) ### "Dummy" Tasks For Interrupted Workflows If using the **Interrupting** setting in a Boundary-type 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-type Event element. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/6ca75dd3-f9de-42a8-875e-d7418748ceb9.png) ### Loops with an Intermediate Timer Event Element As a best practice, avoid modeling a [Script Task](/v1/docs/script-task) element's result to be evaluated by an [Exclusive Gateway](/v1/docs/exclusive-gateway) element, and then returned to the Script Task element on a timed interval set by an [Intermediate Timer Event](/v1/docs/intermediate-timer-event) element. **Bad Practice** The Script Task element runs each time the Intermediate Timer Event element triggers until the Exclusive Gateway element's condition is met. However, if the condition is not met and the loop continues for an extended time, ProcessMaker Platform errors often occur when accessing the Request through the user interface, such as a Task. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/923a01c0-0ca7-4876-9c32-807f43366aab.png) **Good Practice** To avoid this scenario, add a counter to control iterations. For example, the next design shows that the counter can not exceed more than nine iterations to run the Intermediate Timer Event. If the timer is set to run every hour, then, it will be escalated to a task that an administrator can handle to not exceed nine hours. ![](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/a9d52015-1e5f-43a4-a230-1347df2415e7.png) ## Process Documentation ### Write Process Documentation Use [Text Annotation](/v1/docs/text-annotation-and-association-elements) 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 panel.