Either your BPMN diagram is executed by BPMS engine or it must be executed by human performers: each performer shall not only execute the assigned task but also route the process to next task and next performer.
As an example, performer A should pass the case either to B or C depending on the result of Task 1 assigned to him:
Performer A should be aware that it’s his/her responsibility not only to perform the task but also to execute the following XOR gateway. He/she should know what the following BPMN element means and how to process it. It’s clear enough in the example above - everyone would guess it’s a gateway - but other BPMN elements are not that obvious.
I would not even try to instruct an employee how to execute e.g. a non-interrupting boundary escalation as well as most other events. Please keep in mind that if you leverage some BPMN element in a diagram that will be human-powered then you’ll have to train every employee how to handle it. You should also be prepared to mistakes mistakes they will inevitably make. This pressures to keep the active BPMN palette as low as possible.
Service & script tasks? You won’t need them - an automatic procedure launched by a user is a user task, not script neither service.
The BPMN elements worth to be recommended for human-powered processes:
- Pool & Lane
- Data Object, Data Store & Data Flow
- Annotation & Association
- Control & Message Flow
- Tasks: User & Manual; no Script, Service, Business Rule, Send & Receive
- Cycles: Multi-Instance is essential; Loop is excessive hence not recommended
- Subprocesses: Embedded & Reusable, Collapsed only (Expanded is not recommended), Ad-Hoc; Event Subprocess is excessive and complicated hence not recommended
- Gateways: Exclusive & Parallel; no Complex, no Event-Based; Inclusive is excessive and non-trivial hence better to be avoided
- Events: None, Timer, Message (including attached interrupting and non-interrupting), Terminate, Error
- our of scope altogether: Transactions, Compensations & Cancellations
Update: consider leaving send & receive message tasks and message events out of the human-powered BPMN palette. Read more about BPMN messages >>
As we can see, only a handful of BPMN elements are suitable for human-powered processes.
On the other hand, it’s surprising how much can be modelled even with that limited palette. In fact, the better you are in BPMN, the less elements you are using on day-to-day basis.