Which human gates to write before workflow automation
Before workflow automation, write which steps may finish on their own, which steps must wait for a person, and how a stopped run returns to the path people already use. Mark payment, master data, and outbound messages as steps a person completes. While those three have nobody who can claim them, leave the automation off.
On this page
Mark every step before you automate
From intake to handoff, each step names four things: the step, whether a service finishes it or a person does, who may claim it, and where the flow goes after the person finishes or rejects it. Leave any of the four blank and the step stays on the path people already use.
How a flow meets systems you already run is covered under Workflow agents. How a screen robot and an agent that pauses differ is covered in What is the difference between RPA and workflow agents. How a named product connects steps is covered in How to choose between n8n and Make. This note writes the gates. It does not choose a product.
Three task types in the notation
BPMN 2.0.2 was published by the Object Management Group in January 2014, with status formal. The page says the notation is for the stakeholders who design, manage, and realize business processes, and that it is precise enough for a diagram to be translated into software process components. It also says the notation is independent of any particular implementation environment. The normative text is linked from that page under Normative Documents, file formal/13-12-09.
The specification describes a Service Task as a task that uses some sort of service, which could be a Web service or an automated application. Section 10.3.4 says human involvement is needed to complete certain tasks, and it specifies two task types with human involvement: the User Task and the Manual Task. A User Task is executed and managed by a business process runtime. A person performs it with a software application, and a software component called a task manager manages the task life cycle. A Manual Task is not managed by any business process engine. The engine does not track the start or the completion of such a task. The specification’s example is a paper instruction for a telephone technician to install a telephone at a customer location. Potential owners of a User Task may claim it, and after claiming it a potential owner becomes the actual owner. The instance attribute actualOwner returns the user who claimed the task. This note does not quote a package or a price for a product that implements the notation.
Steps that may finish alone
When the rule is already written, the step does not take payment, does not change master data, does not send a message to a customer or a supplier, and a service or an automated application can already be called, mark that step as a Service Task. On the same line, name the service, which record it reads, and which field it writes.
When the rule is still unwritten, or the call would change payment, master data, or an outbound message, keep the step as one a person completes. The Service Task in the specification is a call to a service. This note does not treat “an interface exists” as permission to pay or to send with nobody having read it.
Stop for payment, master data, and messages
Before automation starts, mark payment, a create or update of master data, and a message to a customer or a supplier as steps a person completes. Master data includes the customer, supplier, asset, and item records that later steps will reuse. Outbound messages include email, a short message, and a notice that will appear in the other party’s system.
When you mark one of the three as a User Task, the runtime has to manage claim and completion. When you mark it as a Manual Task, write the completion record in the next section. Both need a named potential owner. With no name, leave the step off the automated path.
How the flow continues after a claim
After a potential owner claims a User Task, the specification says that person becomes the actual owner, and actualOwner returns that user. When the task is complete, the runtime manages the life cycle, and the flow continues at the next step. Write the name of that next step on the gate list.
If the person rejects the case after claiming it, write the rejection back to a named field in the original system, such as an application status or a work-order result. A sentence in a chat that says “done” is invisible to the next step. The write-back is the same requirement as in What is the difference between RPA and workflow agents. This note does not choose the tool again.
Write completion when the engine does not track it
The specification says a Manual Task is not tracked by the engine for start or completion. After work on paper, or outside the system, a person writes a separate record: who finished, when, which case, and whether the result is accepted or returned. Without that record, the automated path has nothing to continue from.
Write that completion into the system and field named on the gate list. When the field does not exist in that system, stop, and add the field before the step resumes, in the same way as How to connect equipment to existing business systems. This note does not assume the engine will fill in a completion time it does not track.
Send a rejection back to the manual path
When a person rejects the case, nobody claims it within the time you have written, or the step cannot be represented as a User Task in the runtime, the case returns to the path people already used before automation. That path names which record to open, who receives it, and whether a finished case re-enters the automated path.
The time limit comes from your own approval rule, with a date. This note does not fill in a number of hours. When the manual path is unwritten, a rejection sits in the runtime, and nobody finishes the case the way it was finished before.
When to leave automation off
When payment, master data, or an outbound message still has nobody who can claim it, or the manual path after a rejection is unwritten, leave the stretch from intake to handoff off automation. Write the gate list first.
This note does not state hours saved, and it does not name a workflow product. The specification page was published in January 2014. Until you have your own gate list, check the automation by whether every step is marked as a service or as a person, whether payment, master data, and outbound messages stop for a person, and whether a rejection returns to the manual path you named.