HITL
Human-in-the-loop (HITL) means incorporating a human decision, review, or approval into an automated process. In business automation, a process can prepare an action, wait for a person, and continue, change, or stop only after that person's decision.
On this page
Source content checked . English translation published 2026-10-27.
In business automation
In business automation, it is not always appropriate to give the system the final decision. It can gather information, prepare a proposal, and check conditions, then pause where human judgment or authority is needed. This lets the person review a decision-ready request instead of doing all the manual work. HITL can also be used in a rule-based process without AI.
When should a person be included in the process?
Human approval is appropriate before sending a customized quote, changing permissions, publishing content, or taking an action when the input is unclear. Define which cases require approval and which can proceed under a fixed rule. If every simple action requires approval, the human queue may become the new bottleneck.
It is important to distinguish approval before execution from review afterward. A notification that says a message has already been sent is not HITL that prevents the send. Handoff to an agent is also different: in a handoff, responsibility passes to a person, while at an approval step the same process can wait and continue after the decision.
Examples
These examples illustrate a possible workflow. Adapt the connections and rules to your own systems.
A quote prepared by the system and approved by a manager
A website form contains the requested service and customer details. The automation collects information from the CRM and prepares a draft quote. It does not send the quote to the customer before an authorized manager makes a decision. This is an example scenario, not a description of an existing customer system.
- The draft is saved with an ID, version, customer, and amount, with a status of pending approval.
- The manager receives a link to the quote and the information it is based on. They can approve, reject, or request a revision.
- The server verifies who made the decision and which version it applied to. Approval of an old draft does not approve a draft edited afterward.
- Sending is triggered only after valid approval. The send ID and result are saved so a double-click does not send the quote again.
The system handles preparation and recordkeeping. The commitment to the customer remains an identifiable decision that can be audited later.
A document with unclear data
An OCR process extracts a document number, date, and amount. When the amount fails a check or an important field is not recognized, the person is shown both the image and the extracted values. They correct or reject the result, and only reviewed information continues to the business system. In this design, it is useful to retain the original value and the correction for investigating errors.
A service agent requests an order change
An agent can read status and answer questions within its defined permissions. An unusual order change is sent to a person along with the customer details, requested change, and reason. Rejection leaves the order in its previous state. The agent explains that the change was not approved instead of trying another tool to perform the same action.
Relevant tools
- n8n
- Includes human review mechanisms for AI agent tool calls. A process can also be designed to wait for a decision, but the approver and the path after rejection must be defined.
- Power Automate
- The Approvals connector includes an action to start an approval and wait for a response. Distinguish this from merely creating an approval request, which does not itself wait.
- LangGraph
- Interrupts let a process pause and resume with external input and saved state. An appropriate persistence mechanism is required, and code at the start of a node may run again on resume.
- Make
- An approval pattern can be built by saving a request and using a form or decision interface to continue the scenario. This is an integration design, not a claim that every scenario includes a built-in approval step.
What to check
- The action must happen after the approval step. Requesting approval at the same time as sending does not stop the send.
- Silence is not approval. Define a waiting period, a reminder, and what happens when time expires: stop or hand off to another owner.
- Show the approver the exact content, destination, and consequence. An approval button without context invites a mistaken decision.
- Check identity and permission on the server, link the decision to the correct version, and verify that the approval request is still valid. A forwarded link should not grant authority.
- Prevent duplicate execution after a repeated click, restart, or retry. Also check rejection, editing, and cancellation while waiting.
- An instruction telling a model to ask for approval is not an enforcement mechanism. The execution tool and process must actually stop until valid approval is granted.