Decide when a workflow step needs a human decision
A human-review step protects a policy-gated action only when it sits at the right point in the workflow and reaches the person who owns the answer. In this unit, you explore how to recognize steps that warrant review, identify who owns the answer and what they provide, and check whether that answer can arrive while the agent waits.
Locate the decision boundary
A step warrants a human gate when proceeding without a person's answer creates a risk that your organization doesn't accept. Common signals include:
- A policy requires sign-off: An authorized person must approve the action, such as an expense above a set amount.
- The input is ambiguous or conflicting: The workflow can't choose correctly from the data it has, so a person decides.
- A second person must check the work: Your process requires someone other than the requester to review the action before it takes effect.
- The action is costly and hard to reverse: A mistake, such as deleting records, costs more than the delay of a review.
In an expense reimbursement, a claim above the review threshold matches the first signal. A missing project code is a different kind of gap: The workflow can't continue until someone supplies a value.
After you find a step that needs an answer, identify the person who can give it. The employee might confirm that they want the agent to submit their claim, but that confirmation doesn't grant the employee authority to approve reimbursement on the organization's behalf. The manager's decision belongs in the workflow, at the point where reimbursement depends on it.
| Pattern | Person who answers | Question and location |
|---|---|---|
| End-user confirmation | The person talking to the agent | Do you want the agent to call this tool? The question comes up in the conversation before the workflow starts. |
| In-workflow decision | The designated reviewer | May the workflow proceed with this action? The workflow asks at the decision point. |
| In-workflow request for a value | The person who owns the missing information | What value does the workflow need to continue? The workflow asks after it identifies the gap. |
End-user confirmation addresses whether the agent should call a tool. In-workflow review controls what happens inside a workflow after it starts. The two address different questions, even when someone calls both an approval. A confirmation from the employee doesn't replace the manager's decision.
In Copilot Studio workflows on the GitHub Copilot harness, the native Request for information action supplies the pause for both in-workflow patterns. The action can ask for a Yes/No decision or collect a value such as text, an email address, a number, or a date. The input type determines what the request asks for.
Match the request to the authority
Once you know where the question belongs, decide what the person needs to provide. If the expense is over your organization's review threshold, the workflow needs permission from someone authorized to approve it. A Yes/No request gives the reviewer a decision that the workflow can use to choose its next step. The threshold is an example of an organizational rule, not a Copilot Studio default.
A missing project code presents a different problem: The workflow needs information. If the employee knows the code and is the right person to supply it, the agent can ask for that input before calling the workflow. If the project owner holds the authoritative code, the workflow can request it from that owner with a text input.
Review the authority as well as the input type. If only a particular manager can approve claims above a limit, route the decision to that manager. If a project owner maintains the code, direct the information request to the owner. When you assign multiple people, the Request for information action uses the first response, so a request to several recipients suits a policy only when one eligible person's answer is enough.
A workflow can also pause through an agent node, a step that hands a task to an agent during the run. With Request human assistance when unsure turned on, the agent decides whether to escalate, and it emails the connection owner instead of an assignee you choose. Because you don't control when that escalation happens or who receives it, use Request for information when a policy requires a specific person's answer. For details, see Add an agent node to a workflow.
Apply the rubric to the reimbursement
For each pause you consider adding, work through four questions. These questions tie each pause to a business rule.
- Who owns the answer? The employee owns the choice to submit the claim. A manager owns a policy decision if your organization assigns that authority to a manager. A project owner owns the code if that person maintains the project's records.
- What happens without the answer? If reimbursement above a threshold requires sign-off, don't let that reimbursement step run before an authorized reviewer answers. If the expense record lacks a required project code, get the code before a step that needs it. A low-risk action with complete, valid inputs doesn't need review solely because a human-review action is available.
- Is the answer a decision or a value? A decision about proceeding calls for a Yes/No input. A project code calls for a value the workflow can use. If both are necessary, treat them as separate questions with the right authority for each.
- Where does the answer arrive? An employee-supplied code can enter as a tool input during the conversation. A manager's decision or an owner-supplied code arrives at a workflow-side request. Place the request before the dependent workflow action, not after reimbursement takes place.
These questions also show when the workflow asks a reviewer for something the employee should have supplied. When a value is required from the employee, define it as a workflow input instead of sending each incomplete claim to a reviewer. Reserve workflow-side review for an authorized decision or a value that the workflow needs from someone other than the employee.
Check the agent's response window
The workflow-side request pauses the workflow until the assignee responds. An agent that calls a workflow as a tool has a separate timing requirement: The workflow uses the When an agent calls the flow trigger and must return its result through the Respond to the agent action within 100 seconds. A reviewer might answer much later. The workflow's ability to wait for that reviewer doesn't extend the agent's response window.
A human request placed before Respond to the agent holds the agent's tool call open until the assignee answers. Place a request there only when the answer can realistically arrive inside that window. If a review can take hours or days, don't design the agent to wait for the decision and report it in the same tool call. For the tool requirements, see Add a workflow as a tool to an agent.
Reflect: In a process you support, which answers belong to the person talking to the agent, which belong to an authorized reviewer or information owner, and which of those answers can arrive within the agent's response window?