Fastfore: All 7 BPMN Task Types Explained

Meet Jessica

Fastfore is a fast-growing consulting company, and growth means one thing above all
else: hiring. Applications are flooding in - dozens every week - and
the process to handle them is pure chaos. CVs get lost in inboxes, interviews are
scheduled over each other, and rejection emails go out three weeks too late.

Jessica, the head of HR, has had enough. She wants an automated workflow that
handles applications from start to finish. But before anyone writes a line of code,
she needs to understand the process - and communicate it clearly to the engineering
team who will build it.

So Jessica draws a BPMN diagram. And because she's designing a process that will
be automated, she uses something beyond the generic task boxes you've seen so far.
She uses task types - seven specific variants that tell you not just
what needs to happen, but how it happens.

  ## Beyond the Generic Task

Every task you've drawn until now has been a plain rounded rectangle - the generic
task. It works for any job. But when you're preparing a process for automation,
"any job" isn't specific enough. The engineering team needs to know: Is this
done by a person in software? By a person with their hands? By a machine? By a script?

BPMN solves this with a small icon in the upper-left corner of the task.
That icon identifies the task type. Seven types, seven icons, seven ways work gets done.
Let's meet them all through Jessica's hiring process - and then see them again
on the factory floor.

  ## The Hiring Process: Happy Path

An application arrives. The first thing HR does is screen the CV and the cover letter.
Jessica's team does this in their HR software - they open a form, review the
documents, and click Accept or Reject.

That's a user task. A person performs the work inside an IT system,
typically by filling out or submitting a form. The icon is a small person with a
monitor. Whenever you see someone working in software - entering data in SAP,
reviewing a case in a CRM, approving a request in a portal - that's a user task.

If the applicant looks promising, the department manager gets notified to review the
profile. That notification is an automated email - no human writes it, no human clicks
Send. The system fires it automatically.

That's a service task. It represents work done entirely by a machine -
calling a web service, triggering an API, executing an automated operation. The icon is
a small gear. No human involvement, pure automation.

  ## Scheduling and Interviewing

The department manager reviews the profile (another user task - same
pattern: person in software, form, decision buttons). If they approve, HR needs to
schedule an interview.

Now here's a question: how does the interview get scheduled? In Jessica's
current process, someone manually scrolls through calendars trying to find a free
slot for both the HR manager and the department manager. That's tedious - but
it's the reality right now.

Once the interview is scheduled, HR sends the invite to the candidate. This is an
explicit act of communication - a person prepares a message and dispatches it. That's
a send task. The icon is a filled envelope. It represents someone (or
something) actively transmitting a message, a document, or a package to a defined recipient.

Quick note: you can model the exact same thing with a generic task followed by a
throwing message event. Both mean the same thing in BPMN. Use the send task when
you're already using task types throughout your process - it keeps things consistent.

After the invite goes out, the process waits. It can't proceed until the candidate
responds. That waiting - actively receiving something from the outside - is a receive
task. The icon is an empty envelope. The key difference from a catching message
event: the receive task implies someone actively receives the response (think
of someone walking to the mailroom and picking up a package), while a catching event
is more passive (an invoice lands in your inbox without you doing anything).

  ## The Interview Itself

The candidate shows up. The HR manager and the department manager sit across the table,
ask questions, evaluate body language, take notes on paper. No software involved. No
screens. Just people talking.

That's a manual task. The icon is a small hand. It represents work
done entirely without IT system interaction - packaging a shipment, conducting a
physical inspection, having a face-to-face meeting.

After the interview, the team evaluates the candidate. They decide: hire or reject.
This evaluation follows strict criteria - minimum years of experience, required
certifications, salary band rules. These aren't gut feelings; they're
documented business rules.

That's a business rule task. The icon is a small table. This task
applies pre-defined rules to reach a decision - a bank checking your creditworthiness
against income thresholds, a quality team verifying samples against compliance norms,
or HR matching a candidate against hiring criteria. Business rule tasks can even be
linked to a formal decision model (DMN - Decision Model and Notation), where the
rules are executed automatically.

  ## The Offer or the Rejection

If the candidate passes, HR sends the offer - a send task. If they
don't pass, HR sends a rejection email - a service task (automated,
no human writes it). Three different outcomes in the process, three different paths,
but every task is now explicitly typed.

And that's Jessica's hiring process. But there's one task type we
haven't seen yet.

  ## The Missing Type: Script Task

Fastfore's hiring process includes a custom assessment: a coding challenge for
engineering candidates. The challenge is evaluated by a script - a small program that
runs the candidate's code against test cases and produces a score.

That's a script task. The icon is a small scroll. Unlike the
service task (which calls an existing external service), the script task
executes a custom script directly in a runtime environment. You wrote the
logic yourself, and it runs right there.

The distinction matters for engineers:

  - **Service task:** You call something that already exists - a Google
      Calendar API, a payment gateway, an email service. You leverage an external capability.

• Script task: You wrote the code yourself and execute it directly.
  A Python script that calculates salary bands based on experience, a scoring algorithm,
  a data transformation.

  ## On the Factory Floor

Fastfore isn't just a consulting firm. One of their largest clients is Space
Z, a spacecraft manufacturer. Let's see the same seven task types in action
on their production line - because task types really shine when physical and digital
work coexist.

The process starts with checking material availability. The planning team looks this up
in their ERP system - a user task. They're in software, querying
a database, reading results on screen.

If parts are missing, they send a purchase order to the supplier - a send task.
When the goods arrive, a warehouse worker physically receives them - a receive
task (someone actively takes delivery, not a passive inbox event).

But what if the supplier doesn't deliver within three days? Someone gets in a car,
drives to the supplier, and picks up the parts manually. That's a manual
task - no IT system involved, just a person and a vehicle.

  ## Planning and Production

Once materials are ready, the planning team creates the production plan in their planning
software - a user task. But the software doesn't cover everything.
The team has built their own script to calculate sample sizes outside the official tool.
That calculation is a script task.

The quality assurance team reviews the plan against pre-defined norms. If the sample
size is below 5% of the production batch, they reject the plan. These are strict,
documented rules - a business rule task.

With the plan approved, the production team adjusts the machines. Workers turn dials,
swap tooling, calibrate equipment. Some machines have interfaces, but the bulk of
the work is physical - a manual task.

Then the machines run. They produce the samples automatically - a service
task. The machines are the service. They were configured, started, and now
they do the work without human intervention.

Finally, quality assurance inspects the samples against compliance norms - another
business rule task. Clear criteria, documented thresholds, pass or fail.

  ## The Golden Rule

Here's the most important principle for choosing task types: when in doubt,
pick the less automated option.

Why? Because when you model a process with task types, you're usually documenting
the as-is process - how things work today. The whole point
is to highlight where automation potential exists. If you label a partially manual task
as a service task, you hide the very inefficiency you're trying to find.

At Space Z, adjusting the machines is a hybrid job - some settings are digital, some
are physical. By marking it as a manual task, you signal to the
engineering team: "This is a candidate for automation." That's far more valuable
than pretending it's already automated.

  > **The golden rule:** When in doubt, pick the less automated task type.

You're documenting the as-is process to highlight automation potential. Don't hide
inefficiencies by labeling manual work as automated.

  ## Why Task Types Matter

Jessica's hiring process, enriched with task types, tells the engineering team
everything they need to build the automation:

  - Three **user tasks** = three input forms needed in the workflow system

• Four service tasks = four automated emails to configure
• Two manual tasks = two steps the system can't automate (yet)

A trained engineer can look at the diagram and immediately derive system requirements.
The user tasks tell them exactly how many forms to build and what fields they need.
The service tasks tell them which integrations to set up. The manual tasks highlight
where human intervention is unavoidable - or where future automation could save time.

That's the real power of task types: they bridge the gap between business
people and engineers. Jessica describes the process she needs. The engineering
team reads it and knows exactly what to build. No lost-in-translation meetings, no
ambiguous requirements documents. One diagram, shared understanding.

  ## The Seven Types at a Glance
  - **User task** - A person works in software (filling a form, reviewing a record)

• Service task - A machine does the work (API call, automated operation)
• Send task - A message or package is dispatched to a recipient
• Receive task - A message or package is actively received by a performer
• Manual task - Work done without any IT system (hands-on, physical)
• Script task - A custom script is executed in a runtime environment
• Business rule task - Pre-defined rules are applied to make a decision

For non-technical processes, generic tasks are perfectly fine. But the moment automation
enters the picture, task types become indispensable. They don't just document what
happens - they document how it happens, and that's what makes a process
diagram actionable.

  > **Seven task types:** User (person in software), Service (machine/API),

Send (dispatch), Receive (accept delivery), Manual (hands-on), Script (custom code),
Business Rule (apply pre-defined rules). Each has a unique icon in the upper-left corner.

---

This is part of the Learn BPMN series on ProcessCamp - 11 real-world scenarios to master process modeling. Try modeling this yourself in Crismo - free, no signup needed.