Human Approval in AI Workflows: Where to Pause Before Taking Action

Put human approval in AI workflows immediately before the action that needs a person's judgment. Publishing a website update or sending a customer message are two examples. Let AI gather information and prepare a proposal, then require an explicit decision before execution. Bind that decision to the exact proposed action, and define what happens when approval expires.

Teams connecting AI to business applications need to decide where preparation ends and permission to act begins. That boundary matters for support tools and content systems alike.

Choose the actions that need approval

List what the workflow can do. Reading a product brief, drafting a reply and publishing a revised product page have different consequences, even when they belong to one task.

For each action, ask whether it affects someone outside the team and how difficult it would be to reverse. Then check whether a fixed business rule can determine if it is permitted.

Adapt these starting controls to the workflow. An internal summary can still expose information to the wrong audience, while some routine messages can follow a tightly defined template.

Anthropic describes permissions that distinguish actions users always allow, actions needing approval and blocked actions. Its example separates reading a calendar from sending an invitation. Set permissions for individual business actions. Broad access to an entire agent leaves those decisions unresolved. See Anthropic's explanation of human control.

Put the approval gate outside the model's discretion

A prompt saying "ask before publishing" expresses intent. The publishing integration should also enforce that requirement.

Design the workflow so the AI can create a proposed change, but the application checks for a valid approval before making the change. Separate draft creation from execution, and restrict the execution tool accordingly.

Microsoft explicitly warns that its computer-use human supervision relies on probabilistic model behavior. A review request might fail to appear when expected or appear unnecessarily. That warning applies to the documented feature, and illustrates why a model's choice to pause should not be your only control. Read the Copilot Studio human supervision documentation.

For example, a website assistant could prepare revised service copy and a preview. A separate publishing step checks the approver, revision and destination before proceeding. If the draft changes, the earlier approval becomes invalid.

For the integration design, see the guide to LLM function calling and workflow orchestration. Approval adds an authorization boundary around those tool calls.

Show reviewers the action they are approving

A reviewer cannot judge a request that only says "Approve the agent's work." Show the proposed action, its destination and the evidence behind it.

An approval request should contain:

• The proposed action and destination, including recipients where relevant.
• The exact draft or a clear comparison of old and proposed values.
• Links to source material, with unresolved assumptions identified.
• The scope, such as one page or a specified set of records.
• The expiry time and available decisions.
• The recovery route if execution produces an unwanted result.

Keep source evidence separate from AI interpretation. A reviewer checking a support response should be able to open the relevant product documentation, rather than relying solely on a generated summary.

For example, Power Automate's approval action includes an assigned approver and request details. Reviewers respond through the supported approval interfaces. Its tutorial then branches on the result. The steps are documented in Microsoft's approval workflow guide. Your platform may expose different fields, so verify its capabilities before choosing a design.

Define waiting, rejection and execution states

Keep a durable status record for human-in-the-loop automation. Use distinct states for proposed, awaiting approval, approved, rejected, expired, executing, completed and failed.

Treat approval and completion as separate events. An approved website change can still fail because the publishing system is unavailable.

Set an expiry appropriate to the task. When it expires, stop the action or route it to a designated backup reviewer. Do not interpret silence as approval. Microsoft documents that unanswered computer-use review requests remain paused and stop at their specified timeout; other workflow products need their own timeout configuration.

Before execution, check whether the underlying item has changed. If another editor updated the page after review began, show the new differences and request a fresh decision.

Plan for retries too. Give each proposed action a unique identifier, and check whether it already completed before trying again. A network timeout does not establish that a message was never sent. These concerns connect directly to state management and event-driven application design.

Avoid approval fatigue and common mistakes

Requesting approval for every read operation can bury consequential decisions among routine interruptions. Group related preparation steps, then pause at a meaningful action boundary.

Avoid these common mistakes:

• Make the final content, target and scope reviewable before execution; a vague plan gives the reviewer too little to judge.
• Check the source and destination. A confident answer can still use the wrong ones.
• Verify the responder's identity and authority instead of accepting approval from anyone with the link.
• Require another review when the action's content or scope changes, rather than reusing the earlier approval.
• Keep tool permissions narrow even when review exists. Approval alone does not make broad access safe.

Approval does not resolve prompt injection. A document or web page can contain instructions intended to manipulate an agent. Treat retrieved material as evidence, not authority to expand the task. Anthropic describes prompt injection as a problem requiring defenses across models, tools and environments, rather than a single safeguard.

Use a practical launch checklist

Before enabling one workflow, confirm that:

• A named owner has defined which actions require approval.
• The execution system rejects missing, expired or mismatched approvals.
• Reviewers can inspect the exact proposal and supporting evidence.
• Rejection and timeout leave the proposed action unexecuted.
• Changed inputs trigger another review.
• Retries cannot silently repeat a completed action.
• Records distinguish approval, execution and failure.
• A team member can stop the workflow and take over manually.

Test each outcome: approval, rejection and no response. Then change a draft after approval and interrupt execution. Check the downstream system to see whether its final state matches the recorded decision.

Start with one bounded workflow, such as drafting and publishing a service-page update. Write down its action boundary, reviewer, expiry rule and recovery process before connecting execution tools. Measure review waiting time, reviewer edits and execution failures during the pilot. Expand autonomy only where those observations support it.