BPMN Tasks & Sub-Processes

BPMN Tasks & Sub-Processes

In the previous lesson you learned how events mark the boundaries of a process. Now we focus on what happens between those boundaries: the tasks that performers execute and the sub-processes that group related tasks into reusable, collapsible units. Understanding task types and sub-process markers is what separates a diagram that merely looks right from one that is analytically precise.

What Is a Task?

A task is an atomic unit of work — work that cannot be meaningfully decomposed further within the scope of the current diagram. In BPMN, every task is drawn as a rounded rectangle. The label inside names the activity, ideally as a verb-object pair: Review Application, Send Confirmation Email, Calculate Invoice Total.

A task with no special marker is a plain abstract task — acceptable early in analysis when implementation details are still unknown. As your model matures, you replace abstract tasks with typed tasks that convey exactly how the work is performed.

The Seven Standard Task Types

BPMN 2.0 defines seven task types, each distinguished by a small icon in the top-left corner of the rounded rectangle:

• User Task (person icon) — a human performer interacts with a software interface. Example: a loan officer opens an application form in a CRM and enters an approval decision.
• Manual Task (hand icon) — a human performs work entirely without system support. Example: a warehouse picker walks to a shelf and pulls an item.
• Service Task (gear icon) — the system calls an automated service or API with no human involvement. Example: a payment gateway is called to charge a credit card.
• Send Task (filled envelope) — the process sends a message to an external participant. Example: a confirmation email is dispatched to a customer.
• Receive Task (empty envelope) — the process waits to receive a message from an external participant. Example: the process pauses until a supplier submits a delivery note.
• Script Task (scroll icon) — the process engine executes an automated script. Example: a nightly batch calculates all overdue fines.
• Business Rule Task (table icon) — a rules engine evaluates a decision. Example: a rule set checks whether an insurance claim exceeds the policy limit.

Task Markers

Separate from the task type icon, BPMN defines markers that appear at the bottom-center of a task shape to modify its looping or instance behavior:

• Loop marker (circular arrow) — the task repeats until a condition is met. Example: Review Draft repeats until the draft passes quality review.
• Sequential Multi-Instance marker (three horizontal lines) — the task executes multiple times, one after another. Example: a manager Approves Budget Request for each of five departments in turn.
• Parallel Multi-Instance marker (three vertical lines) — the task executes multiple times simultaneously. Example: the same approval task runs concurrently for all five departments at once.
• Compensation marker (double left-arrow) — the task is a compensation handler, triggered to undo a previously completed task if the process rolls back.
• Ad-Hoc marker (tilde symbol, on sub-processes only) — contained tasks may be performed in any order at the performer's discretion.

Sub-Processes

When a section of a process becomes complex enough to deserve its own diagram, you promote it to a sub-process. A sub-process looks like a task (rounded rectangle) but has a small plus icon at the bottom-center, indicating it can be expanded into its own flow.

Sub-processes come in two forms:

• Embedded (inline) sub-process — the child flow lives inside the parent diagram and shares the same data context. Expand it by clicking the plus icon.
• Call Activity (thick border) — references a separately-defined, reusable process. Think of it like calling a function. If the same set of steps (for example, KYC Identity Verification) is used in both the account-opening process and the loan-application process, you define it once as a global process and call it from both.

Putting It Together: Online Order Fulfillment

Consider an e-commerce platform. The top-level process has five steps: receive order, validate payment, fulfill order (sub-process), send dispatch notification, archive order. The Fulfill Order step is complex enough to warrant a sub-process containing: pick items, pack items, quality-check package, print shipping label. Meanwhile, Validate Payment is a Business Rule Task (the rules engine checks fraud scores and credit limits), and Send Dispatch Notification is a Send Task (an email or SMS is emitted).

Call Activities vs. Embedded Sub-Processes

A common interview question for analyst roles is: when do you use a Call Activity versus an embedded sub-process? Use a Call Activity when:

1. The same sequence of steps appears in more than one process.
2. A separate team owns and maintains the child process independently.
3. Governance requires that the child process be versioned and audited separately.

Use an embedded sub-process when the grouped steps are unique to this parent process and share its local variables — for example, a multi-step discount calculation that references a running total held in the parent.

Choosing Task Types: A Decision Guide

When you review a business process with stakeholders, ask these questions for each activity:

• Does a person do this, and do they use a system? → User Task
• Does a person do this entirely offline (no system)? → Manual Task
• Is this fully automated with no human trigger? → Service Task
• Does this send a message or notification out? → Send Task
• Does this wait for a message from outside? → Receive Task
• Does this run a batch or transformation script? → Script Task
• Does this evaluate a policy, rule, or decision table? → Business Rule Task
• Is it too complex to show in one shape? → Sub-Process
• Is it reused across multiple processes? → Call Activity

Getting task types right is not cosmetic. It tells the implementation team exactly what kind of component to build — a UI form, a microservice call, an email integration, or a rules-engine evaluation — directly from the diagram, without ambiguity.