Copilot Studio Human in the Loop: Add Review Checkpoints

Copilot Studio human in the loop means a workflow pauses for a person to review information or authorize an action before it continues. Build that pause into the flow before the action that matters; an instruction asking the assistant to be careful is not an approval gate.

A tool such as fenbs can retain the human-approved review rules and the next handoff outside the workflow. The actual checkpoint still belongs in Microsoft’s workflow, where approval can control whether an action runs.

Where should you put a human review checkpoint?

1. Identify the consequential action: sending the final email, changing a customer record, publishing a document, or authorizing a transaction.
2. Keep preparation before the checkpoint. Let the assistant gather permitted information and prepare a proposal that a person can inspect.
3. Insert a supported approval or information-request step before execution. Decide which person can respond and what a valid response means.
4. Make the execution branch depend on the approval outcome. Rejection, missing information, and a failed request must not fall through to execution.
5. Test the whole route with harmless sample data, including a rejected request and a proposal that changes after review.

Say a design studio uses an assistant to prepare client updates. A reviewer needs the actual message and recipient before sending, rather than a general question about whether client updates are allowed. Approval applies to that proposal. A different recipient or revised promise should require another review.

Our guide to human-in-the-loop AI agents explains the broader pattern. Here, the practical job is to make the Microsoft workflow stop at the right point.

Which supported review approach fits your workflow?

Microsoft documents several routes, and they do different jobs. Choose after checking the feature status, environment requirements, and restrictions for your organization. Do not assume every feature with approval in its name requires a person.

For a cloud-flow approach, Microsoft’s standard approvals guide↗ (opens in a new tab) documents Start and wait for an approval. Configure the request and approvers, then explicitly branch on its outcome. Check its prerequisites rather than assuming access to Copilot Studio alone completes setup.

An AI-generated approval is an automated decision. If your policy requires a person, a human stage must actually be reached before the protected action. The distinction between AI in the loop and human in the loop helps when naming that requirement.

How do you configure a native manual approval stage?

Microsoft’s multistage approval instructions↗ (opens in a new tab) describe a preview capability available in agent flows. In the flow designer, insert Run a multistage approval from Human review, select Set up the approval, then choose Create and Manual stage. Set the approval type, Title, Assigned to, and Details.

Choose whether one response is sufficient or everyone must approve. Create inputs inside the approval when you need flow variables, then map the preceding flow values to those inputs after saving the approval. Review the current limitations, including repeated approvers across stages and moving or sharing flows.

Place the consequential action after the checkpoint and inspect how the returned result selects its branch. Draw every possible route on paper if necessary. A human stage that exists on the canvas but can be skipped on the protected route does not meet a mandatory-review rule.

For missing information, Microsoft’s Request for information guide↗ (opens in a new tab) documents adding the action under Human review, setting Title, Message, and Assigned to, and adding response inputs. It pauses the flow and makes the response available to later steps. Its documented restrictions include Outlook delivery, recipients within the same Microsoft organization, and using the first response when several people receive it.

What information should the reviewer receive?

Give the person enough information to disagree. The request should show what will change, the source supporting it, the intended recipient or destination, and the consequence of approval. A polished summary without the proposed action leaves the reviewer guessing.

• Proposal: the exact message, document revision, or record change being reviewed.
• Evidence: the permitted source or reference that supports the proposal.
• Uncertainty: missing facts, conflicting instructions, and assumptions the assistant made.
• Scope: what this approval permits and what still needs separate authorization.

Keep sensitive source material in its approved system and give reviewers appropriate access there. When saving the general rule for future work, fenbs Decisions and rules can hold the person’s choice and reason without duplicating the underlying private records.

How do you test rejection and changed proposals?

Write expected outcomes before testing. For the studio example, rejection should leave the client message unsent. An unanswered request should remain unresolved under the configured waiting and failure behavior. A missing recipient should lead to correction, rather than an invented address.

Test changes between review and execution. If the workflow reads a draft again after approval, verify that it sends the reviewed version or requires review of the revision. Otherwise, a valid approval can accidentally authorize content the person never saw.

Also try a second submission of the same request. Confirm that a retry does not send twice or create a duplicate record. Check what happens when the reviewer lacks access, is unavailable, or declines to respond. Keep a named owner for resolving those cases.

What should survive after the review ends?

Preserve the distinction between approval of one action and a standing rule. “Send this draft” is a decision about one proposal. “A person reviews every external client update” is an ongoing instruction. Saving only the last approval can make the next assistant infer permission too broadly.

Keep the request reference, the person’s decision, its scope, and any remaining work. If a reviewer asks for changes, leave the task unfinished and state what must return for another review. The next person should not have to reconstruct that boundary from a conversation.

How to do this with fenbs

1. Create a free account, then add a project for the agent workflow and a task for its review checkpoint.
2. Record the rule a person approved: which actions require review, who can decide, and what must be shown. Keep proposals open until a person chooses.
3. Add the implementation plan and the approval, rejection, and failure checks to the task. Record what was actually tested and what remains uncertain.
4. Save Where we left off before stopping: the checkpoint configured, the unresolved case, and who must act next. Use the same record for the next AI handoff.

fenbs does not connect to Copilot Studio or run its approval flow. It is useful for keeping the work record; use Microsoft’s approval tools when you need an execution gate. For the surrounding product, start with the Copilot Studio guide, and browse AI governance for related review practices.

Questions about licensing belong in the separate Copilot Studio pricing guide.