Hands On Workflow - DigiBP/digibp.github.io GitHub Wiki
This hands-on gives you a basic introduction to workflow modeling, implementation, deployment, and execution with the CIB seven platform. You will incrementally build a simple pizza service process and explore how BPMN models, user tasks, forms, workflow data, gateways, and collaboration diagrams are handled in an executable workflow.
Contents:
- Use Case Process
- 1. Model the process flow
- 2. User tasks and process execution
- 3. Generated task forms
- 4. Custom task forms
- 5. Gateway and workflow data
- 6. Pools, lanes, and message flows
Use Case Process
The goal is to model and implement a simple pizza service process. We start with a basic process flow and then gradually extend it with executable elements.
1. Model the process flow
Create a new BPMN process for the pizza service.
Model the following basic flow:
- Take pizza order
- Bake pizza
- Deliver pizza
- Process payment
Add an appropriate start event and end event. Use short activity labels following the BPMN naming convention, preferably using a verb and an object.

At this stage, concentrate on the process logic rather than implementation details.
2. User tasks and process execution
Some activities in our process require human interaction. Change the corresponding activities to User Tasks.
Deploy the process and start a new process instance. Then open the Tasklist application and inspect the tasks created by the workflow.

Try to:
- find the task in the All Tasks filter,
- assign a task to yourself,
- complete the task,
- observe how the next task becomes available.
You may also inspect the running process instance in the Cockpit application.
Questions:
- What changes when you complete a user task?
- Which task is active at each stage of the process?
3. Generated task forms
So far, the user tasks do not contain meaningful data. Add a Generated Task Form to the Take pizza order task.
Create the following form fields:
| Field | Variable | Type |
|---|---|---|
| Pizza | pizzaType |
String |
| Address | customerAddress |
String |
| Price | pizzaPrice |
String |
| Solvent? | solvent |
Boolean |
You may use 19.90 as the default value for the pizza price and true as the default value for solvent.
Deploy the updated process and start a new instance. Enter some values into the generated task form and complete the task.
The values entered into the form become process variables and are therefore part of the workflow data.
Questions:
- Where can you see the values entered into the form?
- What happens to the data after the task has been completed?
4. Custom task forms
Generated forms are useful for simple cases, but custom forms provide more control over the user interface.
Create a new CIB seven form, for example pizza-service.form, and add fields for the relevant process data such as:
- Pizza
- Address
- Price
Bind the form fields to the corresponding process variables created in the previous step.
You can also configure individual fields as read-only where users should be able to see information but not modify it.
Assign the custom form to an appropriate user task, deploy the process again, and test it in the Tasklist.
Question:
- What is the difference between a generated task form and a custom form?
5. Gateway and workflow data
The process should only continue if the customer is solvent.
Add an Exclusive Gateway (XOR) after the order has been taken. Create two outgoing sequence flows:
- if the customer is solvent, continue with Bake pizza;
- otherwise, terminate the process with an additional end event such as Order cancelled.

Configure the sequence flows using the solvent process variable. For example:
${solvent}
and
${solvent == false}
Deploy the process and test both paths by starting process instances with different values for solvent.
Questions:
- Where does the
solventvariable originate? - At what point does the gateway evaluate the workflow data?
- What happens when
solventis set tofalse?
6. Pools, lanes, and message flows
Finally, extend the process model to represent the participants involved in the pizza service.
Add a Pizza Service pool and divide it into appropriate lanes for the internal roles. Move the existing activities into the corresponding lanes.
Add a separate collapsed Customer pool and use message flows to illustrate the interaction between the customer and the pizza service.

Remember:
- Sequence flows describe the execution order within one process.
- Message flows describe communication between different participants or pools.
- Lanes can be used to show responsibilities within a participant.
The resulting collaboration diagram should make both the process flow and the organizational responsibilities easier to understand.
Questions:
- What is the difference between a pool and a lane?
- Why can message flows connect pools, but not activities within the same pool?
- Which aspects of the model describe execution logic, and which mainly improve organizational readability?