A workflow is an automation that runs within a case file. It is described as a BPMN model and assembled from a small number of element types. The workflow engine executes these elements in the modeled order; DEPLAW handles the business logic within the tasks.
How to read the diagrams
All workflow diagrams in this documentation use BPMN notation. This short legend is enough to understand them:
Process
The process is the outer wrapper of a workflow – the entire BPMN model that runs in a case file. It can be configured as executable (Startable) and has exactly one start point and one or more end points. A process can embed other processes as a subworkflow (call activity), letting you extract and reuse recurring processes.
Reuse: The thick-bordered call activity in the main process starts a standalone subworkflow. This lets you encapsulate recurring processes once and call them from any number of processes.
Tasks
Tasks are the steps where the actual work happens.
- ServiceTasks are tasks backed by a specific function of the software (e.g. a calculation or a check). Once the engine presents a ServiceTask, DEPLAW executes the associated function and reports the result back. The job type determines which function is executed.
- UserTasks are tasks that require manual input from a user. The workflow pauses at this point until the task has been processed and completed in the case file.
Events
Events mark that something happens – at the beginning, at the end, or during a workflow.
- StartEvent – the entry point of a process. Every execution begins here.
- EndEvent – the end point. Once reached, the workflow ends.
- Catch events catch events that happen within the software, letting the workflow wait and react to them at a defined point (e.g. a change in the case status).
- Timer events let a workflow continue at a specific point in time or once a deadline expires – useful, for example, for deadline monitoring.
Gateways (branches)
Gateways control the flow and split it across multiple paths. DEPLAW mainly uses three types.
| Gateway | Symbol | Behavior |
|---|---|---|
| Exclusive (XOR) | Diamond with × |
Chooses exactly one path based on FEEL conditions – the first one that matches. |
| Parallel (AND) | Diamond with + |
Activates all outgoing paths simultaneously; the merging gateway waits for all of them. |
| Event-based | Diamond with pentagon | Branches based on the first event to occur; the remaining ones are discarded. |
Checks the conditions in order and chooses exactly one path. Always provide a default path ("else").
All paths run simultaneously. The merging gateway waits for all of them before continuing.
Waits for multiple events. The path whose event occurs first wins – the rest are discarded.
Exclusive gateway (XOR) – the classic decision. The conditions on the outgoing sequence flows are checked in order; the first one that matches is followed, all others are discarded. In case no condition matches, you should define a default path, so that the workflow doesn’t run into an incident. Example: “if the open amount > 0, then dunning letter, else closure.”
Parallel gateway (AND) – executes multiple paths simultaneously, without checking any conditions. A merging parallel gateway waits until all incoming paths are complete (synchronization). Suitable for independent steps that can be handled concurrently.
Event-based gateway – branches not based on data, but on events. After the gateway follow multiple waiting events (e.g. several catch events or a timer event). The workflow pauses and follows the path whose event occurs first. Typical use: “wait for a response in the case file – if it doesn’t arrive within the deadline, a timer event takes over the flow.”
Sequence flows
Sequence flows are the connecting arrows between elements. They dictate the order of execution. A sequence flow originating from a gateway can carry a FEEL condition that decides whether this path is taken.