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.
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.
|  | **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. |
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. |
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.
