Branch a workflow on a human decision
Some workflow actions, such as reimbursing a claim above your organization's threshold, can't run until an authorized person explicitly approves them. In this unit, you explore how to request a Yes/No decision before the gated action and branch the workflow so the action runs only after an explicit Yes.
Place the decision before the gated action
In the reimbursement example, the employee submits a claim through an agent. The employee can confirm that they want to submit it, but the manager decides whether an above-threshold reimbursement may proceed. Put the human review between the workflow's threshold check and the action that posts the reimbursement. If the workflow posts first and asks afterward, the decision no longer gates the expense.
The threshold is an organizational rule, not a value Copilot Studio supplies. A workflow might use the amount in the claim to send smaller requests down a path that doesn't require this particular review and larger requests to a manager. The human decision matters on the larger-claim path: Until the reviewer answers Yes, the workflow keeps the reimbursement action out of reach. Other processes use the same placement principle when a policy requires authorization before an account change or a publication step.
The same Request for information action that collects a missing value can also ask for a decision when you give it a Yes/No input. The reviewer needs enough context to answer the policy question, such as the claim identifier, amount, and reason for reimbursement. Put that context in the request's Title and Message, and address Assigned to to someone authorized under your organization's policy. Make the question understandable on its own instead of relying on context from the employee's agent conversation.
Turn the reviewer's answer into a branch
Add a required Yes/No input to the Request for information action. A name such as Approved identifies what the answer means when you use it later as dynamic content. Keep the name free of spaces to avoid the known input-name issue. The question might read, "Do you approve reimbursement for this claim under the expense policy?" Here, Yes authorizes the next step under the example policy, and No means the workflow doesn't post the reimbursement.
Workflows include built-in control structures for branching, as described in Workflows overview. After the request, add a branching step, such as an If/Else condition, that checks the Approved response. The resulting branches express two different workflow outcomes:
- Yes: Continue to the action that posts the reimbursement, using the reviewed claim details.
- No: Skip the posting action and handle the declined claim according to the process, such as recording the decision in the system that tracks the claim. No is an explicit answer from the reviewer, not an error or a missing response.
For example, a manager answers Yes to claim 47821 after checking its amount and policy context. The branching step uses that answer to reach the posting path. If the manager answers No to the same claim, the workflow takes the decline path without posting. The branch depends on the response field from the request, not on whether an email was sent.
When several people appear in Assigned to, the action uses the first response, and later responses aren't processed. Several assignees therefore mean any one eligible reviewer can make the decision, so assign a particular reviewer when policy requires that person's decision. Because the posting action sits only on the Yes branch, the policy rule is enforced inside the workflow.
Separate a missing answer from a No answer
The request pauses the workflow until an assignee submits a response. Until then, the branching step has no Yes or No value to check, so the run doesn't reach either branch and the reimbursement step stays behind the gate.
Think of the three situations as Yes, No, and no answer yet. The first two are values the reviewer supplies. The third describes a wait. A branch on Approved alone doesn't create an escalation, a deadline, or a no-answer path.
Important
Keep the policy-gated action behind an explicit Yes response, and don't treat an unanswered request as No.
The same distinction applies to what you tell the employee: "The manager declined your claim" describes an actual No response, while "The claim is still awaiting review" describes a pending request.
Keep the agent response within its window
If an agent calls this workflow as a tool, the workflow must reach Respond to the agent within 100 seconds, and a manager's review can take longer. Because the request pauses the workflow until the manager answers, don't place a review that can outlast that window before Respond to the agent. Don't design the agent to report a decision that the manager hasn't made yet.
Reflect: For a policy-gated action you support, what evidence lets your workflow take the Yes branch, and can the reviewer's answer arrive within the agent's response window?