Key Takeaways
- Human approval must control whether an action can happen. A prompt asking the AI to be careful is not an access-control mechanism.
- Show the reviewer the exact proposed action, the evidence behind it and any uncertainty that could affect the decision.
- Approval should apply to a specific version. Changes to recipients, amounts, terms or source data may require a fresh review.
- Define rejection, expiry, reassignment, failure and duplicate-action behaviour before the workflow goes live.
- Start with a narrow use case and keep a record of who approved what and what actually happened afterwards.
To add human approval to an AI workflow, separate preparation from execution. Let the system assemble a draft or recommendation, hold the consequential action, and require an authorised person to approve the specific proposal before it proceeds.
That separation is the central design decision. If the AI already has unrestricted permission to send the email, issue the quote or trigger the refund, a polite instruction to ask first leaves too much depending on the model's behaviour.
This article is about building the approval step into the workflow. It is not a recommendation to automate every decision. Some work should remain fully manual, particularly when the context is sensitive, unusual or difficult to verify.
Decide Which Part the AI Is Allowed to Do
Write down the allowed tasks before choosing a tool. For an email, the AI may summarise the enquiry and draft a reply. For a quotation, it may organise requirements and retrieve approved product information. For a refund, it may collect the relevant order and policy details for a person to assess.
Those activities are different from sending, committing a price or moving money. Keep the distinction visible in the interface and the technical permissions.
Our guide to choosing the first AI workflow to automate recommends starting with a bounded process. An approval workflow is easier to test when its inputs, proposed action and responsible team are clear.
Avoid a vague objective such as “resolve customer requests automatically”. It gives neither the developer nor the reviewer a reliable boundary. A better brief says which requests are in scope, what can be prepared and which decisions remain with named roles.
Build an Approval State, Not Just a Chat Message
A workflow needs a durable record of its current state. A message saying “looks fine” in an unrelated chat should not accidentally authorise a financial action.
Use states that the team can understand. A proposal may be drafted, waiting for review, approved, rejected, expired, executing, completed or failed. The names can vary, but the transitions need to be explicit.
Microsoft's Power Automate approval documentation shows how approval requests can form part of a workflow. The presence of an approval feature is only a starting point; the surrounding permissions, data and failure handling still need design.
For example, a rejected proposal should not continue down the same execution path as an approved one. A timeout should not silently count as consent. A failed action should not be marked completed because the approval itself succeeded.
Give the Reviewer Enough Context
An approval button is not meaningful if the person cannot see what they are approving. Put the decision-relevant information in one place, with a route to the original record where appropriate.
For an outgoing email, show the recipient, subject, full message and attachments. For a quote, include the scope, assumptions, price source, exclusions and any unusual terms. For a refund, show the order, proposed amount, reason and relevant policy or exception route.
Highlight uncertainty rather than hiding it inside a fluent summary. If the customer has not confirmed a quantity, the reviewer should see that. If two records conflict, do not present a clean final answer as though the conflict has been resolved.
| Proposed action | Reviewer needs to see | A reason to stop |
|---|---|---|
| Send an email | Recipient, wording, attachments and context | Wrong person or unsupported promise |
| Issue a quotation | Scope, approved pricing and conditions | Missing requirements or unapproved discount |
| Process a refund | Order, amount, authority and reason | Unclear entitlement or duplicate request |
The reviewer should be able to reject or request changes without finding a developer. If the only convenient option is approve, the workflow encourages rubber-stamping.
Check Who Has Authority to Approve
Not every person who can view a request should be able to authorise it. Define approval roles according to the action and the business's existing responsibilities.
A team member may approve routine correspondence but not a contractual commitment. A manager may authorise a refund within a defined limit while a different process applies to an exception. The workflow should enforce those distinctions.
Do not use an AI-generated label as proof that a reviewer has permission. Check the user's identity and authority through the connected system. Keep service credentials restricted to the operations the workflow genuinely needs.
An AI workflow automation project should document both the human decision and the technical enforcement. The person pressing the button and the system carrying out the action are separate parts of the control.
Tie Approval to the Exact Version
Suppose a manager approves a quote, then someone changes the amount or adds a new condition. The earlier approval should not automatically cover the revised proposal.
Record the important fields that were approved and compare them before execution. An implementation may use a version identifier or a digest of the action payload, but the business principle is straightforward: approval applies to this action, not anything the workflow later decides to do.
Decide which changes require another review. A recipient change, new attachment, revised price or altered refund amount normally affects the decision. Even a seemingly minor wording edit can change a commercial promise.
Also consider changes in the underlying record. A refund may already have been processed elsewhere. A quote may rely on stock or pricing that has changed. Recheck the conditions needed for execution rather than assuming they remain true indefinitely.
Make Rejection and Expiry Useful
When a reviewer rejects a proposal, ask for a short reason where it will help the next step. The system can route the work back for correction or close it, depending on the process.
Do not let the AI keep resubmitting the same proposal until somebody approves it. Repeated attempts can create pressure and confusion. Set a clear limit and escalate recurring problems to the workflow owner.
Approvals should also have a sensible lifetime. An email about today's appointment may be useless tomorrow. A commercial offer may need a fresh check after a pricing update. Expiry should return the request to a safe state, not trigger the action by default.
Define what happens when the assigned reviewer is absent. Reassignment should follow an authorised route, and the substitute reviewer should receive the same context. Forwarding an approval notification is not necessarily the same as transferring approval authority.
Prevent Duplicate and Partial Actions
A slow response from a connected service can tempt a workflow to retry. If the first request actually succeeded, the retry may send a second email or attempt a second refund.
Use the connected service's duplicate-protection mechanisms where available, and keep a record that allows the workflow to reconcile the result. The implementation should distinguish “confirmed failed” from “outcome unknown”.
For a multi-step process, define what counts as completion. Creating a draft quote, saving it to the CRM and emailing it are three separate actions. If the email fails after the quote is saved, do not recreate the quote blindly on the next attempt.
These are integration concerns, not problems that better prompt wording can solve. Our AI integration services focus on the joins between systems as well as the model's output.
A Practical Email Approval Example
Consider an illustrative workflow for responding to a new service enquiry. The system reads the submitted request, retrieves the approved service description and prepares a reply. It does not send it.
The reviewer sees the customer's message, the draft reply, the proposed recipient and any unanswered questions. They can edit the draft, reject it or approve the final version. The workflow records that version and checks it again before sending.
If the recipient changes afterwards, approval is invalidated. If the send result is uncertain, the system checks the message record instead of immediately trying again. If the reviewer does nothing before the request expires, the item returns to the team's queue.
This example is deliberately modest. It saves preparation time while leaving the business commitment with a person. It should be tested with fictional or suitably sanitised data before real customer correspondence is enabled.
Test the Uncomfortable Cases
Do not stop after one successful demonstration. Test rejection, an absent reviewer, an expired approval, changed source data, duplicate clicks, a tool timeout and an unauthorised user attempting the action.
Microsoft's agent design canvas guidance includes planning human interaction and the division between autonomous work and human decisions. Use that planning stage to identify where a person genuinely adds judgement, not just another click.
Keep an audit trail proportionate to the process. Record the proposal, approval decision, relevant version and execution result without retaining unnecessary personal information. Review a sample after launch to see whether reviewers understand the requests and whether avoidable exceptions are increasing.
Our AI policy guide can help explain the rules to the team. For more capable systems, the agentic AI buyer's guide covers the wider operating questions. Start an AI agent development project with one action whose approval boundary you can describe and test clearly.
Frequently Asked Questions
Is telling an AI to ask for approval enough?
No. The workflow should technically prevent the consequential action until a valid approval exists. Prompts can describe the desired behaviour, but they should not be the only control over sending, spending or changing records.
What should a human reviewer see?
They need the exact proposed action, relevant source information, important assumptions and uncertainty. For an email this includes recipients and attachments; for a financial action it includes the amount, reason and authority required.
Should a changed quote need fresh approval?
Material changes should invalidate the earlier approval. Define which fields matter, record the approved version and check it before execution. Changes to price, scope, recipient or conditions can alter the decision.
What happens if nobody approves the request?
Use a defined expiry and escalation process. Silence should not count as approval. The request can return to a team queue or move to an authorised substitute reviewer without triggering the action.
How do we avoid the same action happening twice?
Use appropriate duplicate protection and reconcile uncertain results before retrying. Record approval and execution separately so a delayed response does not cause a second email, quote or refund attempt.
