A manufacturing company is hiring and producing samples. Some tasks are done by people in software, some by people with their hands, some by machines, some by scripts. BPMN has a task type for each.
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 justwhat needs to happen, but how it happens.
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 cornerof 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.
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.
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 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.
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.
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 taskexecutes a custom script directly in a runtime environment. You wrote the logic yourself, and it runs right there.
The distinction matters for engineers:
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.
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 - anotherbusiness rule task. Clear criteria, documented thresholds, pass or fail.
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.
Jessica's hiring process, enriched with task types, tells the engineering team everything they need to build the automation:
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.
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 howit 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.
Interactive diagram coming soon
This will be a live Crismo canvas you can explore and edit
Model this process yourself
Open a free diagram in Crismo and build what you just learned. No signup needed.
Open in Crismo →