Human in the loop: automation with human control

If a person has to decide halfway through your process, that does not make the process unsuitable for automation. You automate what is predictable before and after that decision, and an employee decides only where judgement is really needed. This is called human in the loop: automation with human control. It is an option for processes that call for it, not a standard part: many processes can run automatically from start to finish, and you simply automate a decision that you can capture in rules.

What human in the loop is

With human in the loop, a person is a fixed step in an automated process. The software does the preparatory work, puts one concrete question to an employee and finishes the process after the answer. So the employee does not watch everything the software does.

There are two forms. In the first, every case passes a person, for example because every purchase above a certain amount needs approval. In the second, only the exceptions go to a person, such as an order with a price outside the agreed margin. The second form is usually preferable, because most cases then continue without waiting. How this works for orders is explained in automating manual order processing.

How it works: prepare, decide, finish

1. Prepare. The software collects the data, checks it against fixed rules and makes a proposal. What does not fit the rules, it puts in a review queue: the list of cases that an employee reviews.
2. Decide. The employee sees everything in one place and chooses from fixed options. Only this case waits; other cases continue.
3. Finish. The software processes the decision in the ERP (the business system for orders, stock and finance), informs the next department and records who decided what.

In the review queue, the process planner sees the new parts with their drawings, the differences from the previous revision and the open orders on the old revision. A release without new parts or exceptions goes through automatically. The choice between make and buy stays with him; the retyping and searching disappear.

When do you put a person in the process?

Put a person in the process only where they add something. That is usually in one of these situations:

• Real judgement is needed. For example make or buy, or an exception for a customer with a special agreement.
• Someone must be legally or financially responsible. A price far below the agreement, an order above the credit limit or a large purchase needs the approval of someone who is responsible for it. Software can prepare that, but carries no responsibility.
• Technical feasibility must be assessed. Can a configuration just outside the standard be made? Can the workshop meet the requested delivery date of a customer-specific product? An engineer or planner assesses that.
• The input is unclear or incomplete, and you cannot fix that at the source. A scan that the software cannot read with certainty goes to an employee. In UiPath, a person corrects such data in Validation Station (the screen where a person checks data read from documents), also as a task in Action Center (the part of UiPath where an employee handles tasks). If you can change the source, for example with a fixed order form, that is usually better.

When not: if the decision is a rule

A person in the process costs waiting time and attention. If you can write the decision down as rules, automate it. A simple test: can the employee explain to a new colleague how he decides, without "it depends"? Then it is a rule.

If nobody trusts a new automation yet, a temporary check by a person can be sensible. Agree in advance when it stops, for example after a number of weeks without errors. Otherwise a temporary check stays forever.

Designing the decision moment well

Whether human in the loop works depends less on the software than on the design of the decision moment.

1. All information in one place. The reviewer sees the case, the proposal, the reason it stopped and the source, such as the original document or the drawing. Show what deviates: the order price next to the agreed price, the new revision next to the old one. If he still has to search three systems, the automation stops too early.
2. A clear choice. Give fixed options, such as "approve", "reject" and "back to engineering", and ask for a reason from a fixed list on rejection. With free text only, the software does not know what to do next.
3. Deadlines and reminders. An order for today waits less long than an item for a project three months away. Send a reminder before the deadline, and appoint a substitute for holidays and illness.
4. A plan for when nobody decides. The case then goes to a substitute or a manager, or stays with a clear status. Never let software silently approve what you had put to a person. If you find automatic approval acceptable, the decision was a rule. Also watch the platform: in Power Automate (Microsoft software for automating tasks) a flow (an automated series of steps) runs for at most 30 days, after which pending steps such as an approval time out.
5. A log of every decision. Record who decided what, when, based on which data and why. Such a log, also called an audit trail, answers later questions from customers or the accountant, and shows which decisions can become rules. Also define who may decide: only authorised employees, with an amount limit where needed.
6. No blind approval. Someone who gets many cases every day that are almost always right will eventually approve without looking (known as rubber stamping). So send only real decisions, make the exception stand out and do not preselect "approve". Check every month how often the reviewer changes the proposal. Almost never? Then turn it into a rule.

How to set it up

There are three common forms. Choose the place where the reviewer already works: the technology follows the organisation.

• A review queue in the automation platform. This suits employees who handle cases every day. In UiPath, a long-running process waits for a task in Action Center and continues after the person's input. If a task stays open too long, a timer can send a notification or assign the task to someone else. In Power Automate, a flow with the action "Start and wait for an approval" waits for the approvers. You choose whether everyone must approve, the first response counts or approvers decide one after the other.
• An approval by email or Teams. This suits someone who decides now and then, such as a director for a large price deviation. They can answer an approval from Power Automate in an Outlook email or a card in Teams. Check which licence they need for this. With many requests, they quickly lose the overview in their mailbox.
• A status or worklist in the ERP. This suits decisions about data that is already in the ERP. Microsoft Dynamics 365 Business Central (an ERP package), for example, has approval workflows for purchase and sales documents and item cards, among others, with amount limits per approver. An approver can delegate a request to a substitute. A document stays locked until it is approved. The automation reads the status and then continues. Ask your supplier what your ERP can do.

Alternatives: five ways to handle a decision

The last approach is less obvious. If engineering can record the choice between make and buy in the PDM, the decision moment after each release disappears. Sometimes such a small change in the process is better than a well-designed decision moment. See also when it is better not to automate a process.

Decision framework: does your process need a person?

Ask these questions internally before you design a decision moment:

1. Which decision does the employee make exactly? Write it down as one question with fixed answers.
2. Can he explain how he decides? Count for a few weeks how often he deviates from what the rules would say.
3. Who is responsible, and who stands in for them?
4. How long can a case wait before it does damage?
5. Where does the reviewer already work, and can the decision be made earlier in the process?

What weighs most is the number of cases for a person, the waiting time your company can accept and whether it is really a matter of judgement. Many cases with almost always the same outcome point to rules that have not been written down yet.

Outside help makes sense if you are not sure which decisions are rules, or if the decision moment touches several systems, such as PDM, ERP and email. A process analysis then shows where the judgement really sits, before anything is built. Which work is suitable for automation is explained on the services page and in the article on whether your process can be automated.

Limitations and drawbacks

• Waiting time. A step with a person makes the process slower. Use it only where waiting is acceptable.
• Too many decisions. If a large share of the cases reaches a person, the rules or the data are not in order. Improve those, instead of having more people look at the review queue.
• Dependence on people. A review queue without an owner, a substitute and fixed times fills up. You often notice only when a customer calls.
• False security. A person in the process does not replace tests, error handling and monitoring. What happens when these are missing is explained in why RPA projects fail.
• Maintenance. Options, forms and deadlines change with the process, just like the rest of the automation.

Conclusion

The question is not whether a process can do entirely without a person, but where exactly the judgement sits. Sometimes that is one decision in a process of ten steps, and sometimes there is none. Keep that moment small and well prepared, and automate the rest. After that, turn every decision that always comes out the same in the log into a rule.

Sources

• UiPath Documentation: Introduction (Action Center)
• UiPath Documentation: Configuring task timer (Action Center)
• UiPath Documentation: Validation Station
• Microsoft Learn: Get started with Power Automate approvals
• Microsoft Learn: Limits of automated, scheduled, and instant flows
• Microsoft Learn: Approve or reject documents in workflows (Business Central)