Abstract Task
The generic, untyped unit of work in BPMN — a rounded rectangle with no marker icon. It states that work happens at this point without specifying how that work is performed.
The Abstract Task (often just called Task) is the base activity of BPMN 2.0. All the specialized task types — User, Service, Send, Receive, Manual, Script and Business Rule — are refinements of it, each adding a marker icon and execution semantics.
An abstract task is deliberately non-committal: it says *what* is done, not *who or what* does it. That makes it the natural choice for early-stage, descriptive process models, where the goal is to agree on the flow of work before deciding on implementation details.
When to use and avoid
When to use
During discovery workshops and early drafts, when the mechanism of each activity has not been decided yet.
In descriptive models aimed at business readers, where marker icons would add noise without adding understanding.
As a placeholder to be refined later into a typed task (User, Service, etc.) when the model becomes executable.
When NOT to use
In executable models deployed to a process engine — the engine needs a concrete type to know how to run the activity.
When the distinction between human and automated work matters to the reader — use User Task or Service Task to make it explicit.
For sending or receiving messages — Send Task and Receive Task carry that semantics; an abstract task does not interact with message flows by itself.
Business example
Order fulfillment sketched with generic tasks
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The process starts when an order is received.
- The abstract task “Check stock availability” (highlighted) records that stock is verified here — the model does not yet say whether a person or a system does it.
- Pack order follows, and the process ends with the order ready for shipping.
This is a typical descriptive model: the flow is agreed first; task types are assigned later, when the team decides what gets automated.
Differences
Difference between an Abstract Task and the typed tasks
The abstract task carries no execution semantics — it only marks that work happens. The typed tasks (User, Service, Send, Receive, Manual, Script, Business Rule) each add a marker icon and tell a process engine exactly how to execute the activity. Use abstract tasks while modeling for understanding; assign types when the model must run.
Difference between a Task and a Sub-Process
A Task is atomic: it cannot be broken down further within the model. A Sub-Process is compound: it contains its own flow of activities, gateways and events. If you feel the urge to describe steps *inside* a task, it should probably be a sub-process.
FAQ
Can a process engine execute an abstract task?
Most engines either reject it or treat it as a pass-through/manual step, depending on the vendor. For executable processes, always choose a concrete task type.
Is it wrong to publish a final model that still uses abstract tasks?
Not for descriptive documentation — many organizations keep business-facing models untyped on purpose. It only becomes a problem when the model is meant to be deployed to an automation engine.