Implement a request-for-information pattern

Completed

Some workflows can't finish a step until someone other than the requester supplies a missing value, such as a project code that the employee doesn't know. In this unit, you explore how to request that value from a designated person inside a Copilot Studio workflow and use the answer in a later workflow step.

Decide who supplies the missing value

Suppose the reimbursement workflow checks the expense record and finds that its project code is blank. The code comes from the project owner, who maintains the project's records. In that situation, a workflow-side request reaches the person who can supply the value before the workflow uses it. The employee's decision to submit the claim answers a different question.

If the employee already knows the code and is authorized to supply it, the agent can ask for the code during the conversation and pass it as an input when it calls the workflow. If the project owner holds the authoritative value, the workflow can request it after identifying the missing field. Use the answer's owner and the point at which the gap becomes known to choose where to ask. A workflow-side request is especially useful when the need for a value depends on data the workflow reads or computes after it starts.

In this example, the workflow checks the expense record before its reimbursement step. If the record has a usable project code, the workflow doesn't need a request for that field. If the code is missing and the project owner supplies it, place the request before the step that needs the code. This placement keeps the human request tied to a specific missing value instead of adding a review pause to every claim.

Configure the request for the project owner

In Copilot Studio workflows on the GitHub Copilot harness, you add the Request for information action by selecting Add a step and searching for Human review. Place the action at the point where the workflow needs a person to supply information. The action pauses the workflow for the assignee's response, and the response becomes available to later workflow steps. For the documented action and configuration, see Request information from human review in workflows.

The action requires three fields. Give each field a distinct job in the reimbursement example:

  • Title: Identify the request in the subject line of the email, such as Project code for reimbursement 47821. A specific title helps the owner recognize which claim needs attention.
  • Message: Explain what the owner needs to supply and why. Include the relevant expense identifier from an earlier workflow step so the owner can match the request to the claim. Don't assume the owner sees the employee's conversation with the agent.
  • Assigned to: Enter the project owner's email address. If more than one eligible owner can answer, the action can address multiple people. Choose assignees based on who has authority to provide the value, not merely who is available.

For this action, requests go through Outlook to people in your tenant. You can't use the action to send a request to an external project owner. With multiple assignees, the workflow uses the first response and doesn't process later responses. Assigning several people therefore works only if any one of them can provide the authoritative code.

The Title and Message explain the request, while the input field defines the value that the assignee returns. Keep that distinction when you draft the message: A note that says "send me the project code" doesn't create a project-code input the workflow can use. Define the input explicitly so the answer becomes data for the next action.

Shape the response as workflow data

For the reimbursement, add a Text input named ProjectCode. Use placeholder text to describe the expected answer, such as Enter the project code for this claim. Keep ProjectCode required, because the workflow can't proceed without the code. You can make an input optional by selecting Make the field optional when a later step can operate without its answer. For example, an optional note from the owner can provide context without replacing the required code.

The action offers five input types. Match the type to the answer the workflow needs, not to the role of the person answering:

Input type Value to collect in an expense process
Text A project code or an explanation from the owner. A text input can also offer single-select or multi-select choices for a defined set of values.
Yes/No A decision about whether the workflow may proceed. A later workflow step can branch on the reviewer's Yes or No answer.
Email An email address for an expense contact.
Number An integer value, such as a whole-number reference used by the process.
Date A date relevant to the claim.

The project code remains a Text input even if it contains digits, because the value identifies a project rather than measuring a quantity. If a workflow needs a guided choice instead of free text, provide options on a Text input and make sure the choices correspond to values the workflow handles. The question the owner answers then matches the data the later step expects.

Use input names without spaces, such as ProjectCode. A known issue affects input names that contain spaces: The response can occasionally appear wrapped in {{ }} when you use the value later.

Use the response in later workflow steps

After the project owner answers, ProjectCode is available as dynamic content in subsequent workflow actions. In the reimbursement example, a later step uses that value where it needs the project code. You can ask for more than one value in the same request and use the corresponding responses separately. Keep a request focused on values the assigned person can supply: Adding unrelated questions makes it harder to tell which answer a later step needs.

If an agent calls this workflow as a tool, the workflow must still reach Respond to the agent within 100 seconds. A request placed before that action fits only when the owner can answer inside that window.

Reflect: In a process you support, which value does a workflow need from someone other than the person who starts it, and which input type captures that value?