111 lines
6.0 KiB
Markdown
111 lines
6.0 KiB
Markdown
# Pools and Lanes
|
||
|
||
A Pool represents a participant and can be seen as a self-contained process.
|
||
This participant can be an internal entity (e.g., a department within a company) or an external entity (e.g., a customer or another company).
|
||
Lanes are helpful in highlighting which specific role or department is responsible for certain activities or tasks in a process.
|
||
A process can have one or more Pools, each with one or more Lanes.
|
||
|
||
**Reasons to Use Pools and Lanes:**
|
||
|
||
- They visually represent distinct participants in a process, such as various departments, organizations, or systems.
|
||
- They help depict interactions between separate business entities, like a buyer-seller dynamic.
|
||
- They provide a clear overview of communication between different participants.
|
||
- They categorize tasks or activities based on specific roles.
|
||
- They bring structure and organization to complex diagrams that involve multiple roles, departments, or stakeholders.
|
||
|
||
|
||
## Pools
|
||
|
||
A Pool can be configured as an "Empty Pool" (collapsed) or an "Expanded Pool".
|
||
You can choose the desired configuration 🔧 from the element's options after dragging it onto your diagram.
|
||
|
||
|
||
|
||
Empty Pools are used to represent role players in cases where a specific process is neither known nor required, but the interaction points remain valuable.
|
||
They serve to illustrate the engagement of certain entities without detailing their internal processes, for example, we don't know a customer's specific process but it matters when we interact with them to complete our process.
|
||
|
||
Conversely, Expanded Pools are employed when the processes are known and hold relevance within the diagram's context.
|
||
|
||
## Lanes
|
||
|
||
Lanes group activities within a single Pool, usually signifying different roles or departments.
|
||
|
||
|
||
|
||
Lanes are incorporated into Pools when the roles they represent belong to the same entity.
|
||
However, if a process doesn't logically fit within the same Pool, like those for different organizations or businesses, it's more appropriate to represent it as a separate Pool rather than another Lane.
|
||
|
||
|
||
|
||
## Configuration
|
||
|
||
|
||
|
||
**Collapsed (Empty) Pool configuration:**
|
||
|
||
Configuring an "Empty Pool" (collapsed) to represent an external entity such as a customer.
|
||
|
||
| 💻 Form | ⌨ Field Input | 📝 Description |
|
||
| --- | --- | --- |
|
||
|  | **Participant Name:** Sales, **Participant ID:** sales, | A clear and descriptive name serves as a human-readable label or title for the participant. Additionally, a unique ID is essential to distinguish the participant from other participants. |
|
||
|  | **Data Objects:** order_details | Create or Reference a Data Object to store information for sharing between entities. |
|
||
|
||
**Expanded Pool configuration:**
|
||
|
||
Setting up an "Expanded Pool" requires referencing the process, in contrast to the setup of an empty pool.
|
||
|
||
| 💻 Form | ⌨ Field Input | 📝 Description |
|
||
| --- | --- | --- |
|
||
|  | **Participant Name:** Sales, **Participant ID:** sales, **Process ID:** process_order, **Process Name:** Process Order | A clear and descriptive name serves as a human-readable label or title for both the participant and the process. Additionally, a unique ID is essential to distinguish both the participant and the process from others. |
|
||
|  | **Data Objects:** order_details | Create or Reference a Data Object to store information for sharing between entities. |
|
||
|
||
**Collapsed Pool configuration:**
|
||
|
||
|
||
|
||
Remember that each pool requires Lane configuration, even if it contains just a single Lane.
|
||
|
||
|
||
| 💻 Form | ⌨ Field Input | 📝 Description |
|
||
| --- | --- | --- |
|
||
|  | **Name:** Manager | A concise and descriptive label that accurately represents the owner and role of the Lane. |
|
||
|  | **ID:** lane_manager | A distinct ID to differentiate each Lane, especially when there are multiple. |
|
||
|
||
### Example: Using Lanes and Pools for Petty Cash Request Process
|
||
This example demonstrates the application of Lanes and pools in a BPMN diagram, specifically designed to handle a petty cash request process within an organization.
|
||
|
||
The process is structured around different tasks allocated to lane and pools, emphasizing role-based access and task execution.
|
||
|
||
|
||
#### BPMN Diagram
|
||
|
||
|
||
**Process Flow:**
|
||
|
||
1. **Start Event**: The workflow kicks off with a start event signaling the initiation of a petty cash request.
|
||
|
||
2. **User Task: Petty Cash Request**: This task uses a form to collect petty cash requests, including the requested amount and the reason for the request.
|
||
|
||
|
||
|
||
The process transitions from the Requester Lane to the Cashier Lane within the Cashier Pool for approval.
|
||
|
||
3. **User Task: Approve Petty Cash**: In this task, cashiers review and approve the petty cash request, recording the approver’s name for accountability.
|
||
|
||
|
||
|
||
After approval, the workflow returns to the Requester Lane for final confirmation and display of the approval outcome.
|
||
|
||
4. **Manual Task: Display Output**:
|
||
|
||
**Display Message**:
|
||
|
||
```markdown
|
||
Your petty cash request for {{amount}} has been approved by {{approved_by}}
|
||
```
|
||
This message informs the requester of the approval status, including the approved amount and the name of the approver. After manual task, marks the end of the process.
|
||
|
||
|
||
|
||
|
||
This BPMN diagram effectively uses Lanes and pools to structure a petty cash request process, ensuring that responsibilities are clearly assigned and the workflow is logically organized. |