If you've ever stared at a BPMN diagram and wondered why some task boxes look different from others with little icons in the top-left corner you're looking at task types. Getting these wrong means your process model becomes ambiguous, developers misinterpret your intent, and automation breaks down. Understanding how BPMN task types are classified and when to use each one is a foundational skill that separates a readable process diagram from a confusing one.

What exactly are BPMN task types?

In BPMN, a task is the most basic unit of work in a process the single action someone or something performs. But not all work is the same. A person filling out a form is fundamentally different from a system automatically sending an email. That's why BPMN defines several task types, each represented by a small marker icon in the upper-left corner of the task shape.

The classification exists because process models need to communicate how work happens, not just what happens. Without task types, a reader wouldn't know whether a step is manual, automated, or involves waiting for something. You can learn more about how tasks fit alongside other elements by reviewing how BPMN gateways control process flow.

How are BPMN task types classified?

The BPMN 2.0 specification, maintained by the Object Management Group (OMG), classifies tasks into six main types based on the nature of the work performed:

• User Task Work performed by a human with the help of a software application
• Manual Task Work performed entirely by a human, without system support
• Service Task Work executed by an automated service or system
• Script Task Work performed by a script or code executed by the process engine
• Business Rule Task Work that evaluates a business rule or decision
• Send Task Work that sends a message to an external participant
• Receive Task Work that waits for a message from an external participant

There's also the generic Task (no marker icon), used when the type doesn't matter or hasn't been decided yet. Each type carries specific semantics that process engines and developers rely on for implementation.

When should I use a User Task instead of a Manual Task?

This is one of the most common points of confusion. A User Task means a person does the work, but they use a software system to do it like approving a request in a BPM platform or filling in a web form. The system creates a work item in someone's task list.

A Manual Task is fully offline or analog work signing a physical document, having a face-to-face meeting, or inspecting a warehouse. No software system is involved in completing it.

Example: In an employee onboarding process, "Fill out tax forms in the HR portal" is a User Task. "Collect signed physical ID copies" is a Manual Task.

What's the difference between a Service Task and a Script Task?

Both are automated, but they differ in where the work runs.

A Service Task calls an external service typically a web service, REST API, or external application. The process engine delegates the work outside itself. For instance, "Charge customer credit card via payment gateway" or "Send data to CRM system" are Service Tasks.

A Script Task runs code inside the process engine usually a snippet written in Groovy, JavaScript, or another supported language. It's often used for data transformation, calculations, or logic that doesn't require external calls. For example, "Calculate discount based on order total" or "Format output data as JSON."

How do Send Tasks and Receive Tasks work?

These two work as a pair. A Send Task dispatches a message to another process or participant and then moves on. A Receive Task pauses the process and waits until a specific message arrives.

Use case: A procurement process sends a purchase order to a supplier (Send Task), then waits for the supplier to confirm the order (Receive Task). This is different from BPMN message events because message tasks represent work that's tied directly to the activity, not an interrupting boundary condition.

When does a Business Rule Task make sense?

Use a Business Rule Task when a step in your process delegates a decision to a business rules engine like Drools, DMN-based decision services, or a custom rules platform. Common examples include "Determine loan eligibility," "Evaluate insurance claim amount," or "Classify customer risk level."

If your organization doesn't use a dedicated rules engine, you probably don't need this task type. A Script Task or a regular Service Task can handle simpler decision logic.

What are common mistakes with BPMN task types?

1. Using generic tasks everywhere. Leaving every task as a plain box with no marker forces readers to guess what kind of work is happening. It also loses critical information for automation.
2. Confusing User Tasks with Manual Tasks. If someone uses a screen, it's a User Task. If they don't, it's Manual. Mixing them up misleads developers about system integration requirements.
3. Overusing Service Tasks for simple logic. Not every automated step calls an external API. If the process engine runs the logic directly, a Script Task is more accurate.
4. Ignoring Send/Receive Tasks in cross-process communication. Using message events instead of message tasks when the communication is the core purpose of the activity can make diagrams harder to follow.
5. Using task types inconsistently across a model. If similar work is labeled as a User Task in one place and a Manual Task in another, the diagram loses credibility.

Practical tips for choosing the right task type

• Ask "who or what does this?" first. If the answer is "a person with software," use User Task. "A person without software," Manual Task. "A system," Service Task. "A rules engine," Business Rule Task. "A script inside the engine," Script Task.
• Be consistent within your organization. Agree on conventions and document them. If your team has a style guide, task type definitions should be in it.
• Use the generic task as a placeholder, not a final answer. Start with a plain task during discovery workshops, then assign the correct type during detailed modeling.
• Keep your audience in mind. Business stakeholders often don't care whether something is a Service Task or Script Task. Use task types that add meaning for the people reading the diagram.
• Pair task types with proper event handling. For example, if a Service Task might fail, model error boundaries using BPMN event definitions and trigger types rather than embedding exception logic inside the task itself.

Quick checklist: BPMN task type selection

• ☐ Identified whether the work is human, automated, or rule-based
• ☐ Distinguished between system-assisted (User) and system-free (Manual) human work
• ☐ Clarified whether automation runs inside the engine (Script) or calls an external service (Service)
• ☐ Used Send/Receive only when message exchange is the task's primary purpose
• ☐ Reserved Business Rule Tasks for dedicated rules engine calls
• ☐ Applied consistent task type conventions across the entire process model
• ☐ Removed any remaining generic (untyped) tasks before finalizing the diagram

Next step: Open your most recent BPMN diagram and audit every task box. For each one, ask: "Does this task type accurately describe how the work happens?" Replace any generic tasks with the correct type. If you find inconsistencies, document a one-page task type convention guide for your team and share it before your next modeling session.