In BPMN 2.0, how do the user, manual, service, script, business-rule, send and receive task types differ?
answer
- who or what does the work
- engine-managed versus unmanaged human work
- rules engine in, decision out
- envelope fill shows direction
basics
~20 sIn BPMN 2.0 the task type says who performs the work: a user task is human work the engine tracks, a manual task is human work it does not, service, script and business-rule tasks are automated, and send and receive tasks exchange messages.
solid answer
~50 sBPMN 2.0 types a task by who or what performs it. A **user task** is done by a person with software help and its lifecycle is managed by a task manager; a **manual task** is done without any engine or application, so the engine does not track its start or end. A **service task** calls a service, such as a web service or an automated application; a **script task** runs a script the engine itself interprets; a **business-rule task** sends inputs to a business rules engine and gets its outputs back. A **send task** sends a message to an external participant and completes once it is sent; a **receive task** waits for one and completes on arrival. In a loan approval: credit-bureau check is a service task, eligibility rules a business-rule task, underwriter review a user task, and waiting for the signed offer a receive task.
go deeper
Recall the seven task types and who performs each: person with a system, person without, service, engine script, rules engine, and message send or receive.
Explain the managed versus unmanaged distinction between user and manual tasks, and when a receive task instead of an event is the better fit.
Choose task types so an executable model behaves correctly: human steps the process must wait on are user tasks, and rule decisions are business-rule tasks.
Set typing conventions across process models so automation candidates, human workload and rules ownership can be read straight from the diagrams.
## Why task types exist A **task** in BPMN 2.0 (OMG formal/13-12-09) is an atomic activity: work that is not broken down further in the model. Every task is a rounded rectangle drawn with a single thin line. A task with no type is an **abstract task** (called the "None Task" in BPMN 1.2). The **type**, shown by a marker in the upper-left corner, tells the reader who or what performs the work, and therefore whether a person is in the loop and whether an engine can run it. ## The seven typed tasks | Task type | Performed by | What the engine does | Marker | |---|---|---|---| | User | a person, helped by software | distributes it to people and tracks its lifecycle through a task manager | human figure | | Manual | a person, no application | nothing: it is not managed or tracked by any engine | hand | | Service | a service or automated application | invokes the service (a web service by default) | service marker | | Script | the engine itself | runs a script written in a language it can interpret | script marker | | Business rule | a business rules engine | sends inputs, receives the calculated outputs | rule marker | | Send | the engine | sends a message to an external participant, then completes | filled envelope | | Receive | the engine | waits for a message from an external participant, completes on arrival | unfilled envelope | The execution semantics chapter sums up each one: a user task is distributed to the assigned person or group and completes when the work is done; a manual task is also distributed, but "is never actually executed by an IT system"; a script task invokes its script and completes when the script does; an abstract task completes as soon as it is activated. ## The distinctions interviewers probe - **User versus manual.** Both need a human. The difference is management: the specification says a user task is executed by and managed by a business process runtime, while a manual task is neither executed nor managed by one. If the engine must know when the work started and finished, it is a user task. - **Service versus script.** A service task hands the work to something outside the engine; a script task is run by the engine. A script task without a script behaves like an abstract task. - **Service versus business rule.** Both are automated, but a business-rule task is specifically a call to a **rules engine** with inputs and outputs: a decision, not an arbitrary operation. - **Send and receive versus events.** A send task and a receive task carry the same envelope markers as a throwing and a catching message event. A task can carry markers such as loop or multi-instance and has an activity lifecycle; an event cannot. A receive task can even start a process when its `instantiate` attribute is true and it has no incoming sequence flow. ## A loan-approval process, typed 1. **Receive application**: a receive task with `instantiate` set to true, so the arriving application message starts the process. 2. **Pull credit report**: a service task calling the credit bureau's service. 3. **Evaluate eligibility**: a business-rule task that sends income, debt and score to the rules engine and receives an eligibility decision. 4. **Calculate arrangement fee**: a script task, since it is a small calculation the engine can run itself. 5. **Underwriter review**: a user task, because an underwriter must judge the file and the engine must know when the review is done. 6. **Verify identity documents in the branch**: a manual task if the branch officer checks the originals in person and no system records the step; a user task if a screen captures the result. 7. **Send loan offer** and **Await signed offer**: a send task and a receive task. ## Common mistakes - Marking human work as a **manual** task when the process must wait for it: nothing tells the engine when a manual task ends. - Using a **service** task for a rules decision that the organisation maintains in a rules engine; the business-rule task says what the step is. - Treating task type as decoration. In an executable model the type decides what the engine does at run time. - Forgetting the **abstract** task exists: an untyped task is valid in a descriptive model but executes as a no-op. - Assuming every type can be defined once and reused as a global task. The specification defines global versions only of the user, manual, script and business-rule tasks.
- In BPMN 2.0, when should a human step be a user task rather than a manual task?When the process needs the engine to assign, track and complete the work. A user task is managed by a task manager and completes when the performer finishes it in the system; a manual task is never executed by an IT system, so the engine cannot know when it ended.
- In BPMN 2.0, can a receive task start a process instance?Yes. If its `instantiate` attribute is true and it has no incoming sequence flow, the arriving message creates the process instance, and its envelope marker is drawn like a message start event.
Task types are like job descriptions on a shift roster: the roster says whether the job goes to a person with a terminal, a person with a clipboard nobody collects, or a machine.
saying these in an interview costs you the question
- A manual task is simply a user task done on paper, tracked the same way.
- A script task is executed by an external service, like a service task.
- Send and receive tasks behave exactly like message events, markers included.
- An untyped task is invalid BPMN.
- A business-rule task is just a service task with a different icon.