5.2 Input and Output Parameters

5.2 Input and Output Parameters

Quick Answer: Define inputs on the When an agent calls the flow trigger and outputs on Respond to the agent. Prefer Text, Boolean, and Number types the agent can invoke reliably. Bind inputs from topics (Power Fx/variables) or generative tool fill modes. After any schema change, refresh the flow on the agent. Keep Asynchronous response Off and return outputs inside the ~100-second agent action window.

Parameters are the API contract between conversational intelligence and deterministic automation. If the contract is vague, mistyped, or stale, the flow may succeed while the agent fails—or the agent may never call the flow. AB-620 expects you to design that contract deliberately.

The required shape of an agent-callable flow

For a flow to be usable as an agent tool, Microsoft requires:

1. Trigger: When an agent calls the flow
2. Terminal (for the agent’s wait): Respond to the agent with the outputs the agent expects
3. Asynchronous response set to Off under Networking on the respond action (real-time response)
4. Response within the 100-second action limit for the agent-facing path

Long-running work that is not needed in the chat reply can run after Respond to the agent (flow duration can extend much longer—on the order of days for cloud flow limits—but the agent will not wait past the action timeout).

When you create a new agent flow from Copilot Studio as a tool, the starter template already includes the trigger and respond actions. When you convert or retrofit an existing automation, you must add this pair yourself.

Defining input parameters

On the When an agent calls the flow trigger, add one input per piece of data the flow needs from the agent.

Design rules

Typing guidance (exam-critical)

Microsoft’s flow error documentation is explicit that when invoking Power Automate / agent flows from the agent, Text, Boolean, and Number are the supported parameter kinds for this invocation path. If you declare exotic types the agent cannot pass, expect bad-request failures. Align topic variables’ base types with flow parameter types before go-live.

Examples

Files deserve special care: passing user files into agent flows is supported in documented patterns (question node → flow variable, or tool Inputs configuration), but incomplete file payloads produce errors such as invalid model input parameters when content bytes are missing. Always validate required file parts in the flow before calling AI prompt or LOB actions.

Defining output parameters

On Respond to the agent, declare every value the agent must use next—ticket number, status message, boolean success flag, formatted summary for Adaptive Cards, and so on.

Output design rules

1. Return only what the conversation needs. Excess fields increase payload risk (TooMuchDataToHandle, outgoing message size issues).
2. Always populate declared outputs on success paths. Missing expected outputs yield FlowActionException (“no output received” / named output missing from response data).
3. Include an explicit success or error code output when you implement structured error handling (next section). That lets topics branch without parsing free text.
4. Keep schema stable across environments via solutions; breaking renames force agent rebinding.

Binding parameters on the agent (tool configuration)

After the flow is published, add it under the agent Tools page (Add a tool → Flow).

Configure:

1. Name and Description — written for the orchestrator: when to call this flow, what it does, and what inputs mean.
2. Inputs — for each parameter, choose how the agent fills the value:
   • Dynamically from conversation context (generative fill based on description)
   • Explicitly with a fixed value or Power Fx expression / topic variable
3. Completion — what the agent should do after the tool finishes (continue reasoning, respond to user, etc., per UI options).

Topic binding vs generative tool binding

Exam trap: Using generative fill for a field that must be a controlled enum without validation. Prefer collecting the value in a topic (Adaptive Card choice set) and binding explicitly, or validate inside the flow and return a clear UserMessage when invalid.

Defaults, optional inputs, and validation

Agent flows do not replace validation—you design it:

• Mark only truly required inputs as required on the trigger.
• Supply defaults in the flow when business rules allow (for example default Urgency = 3).
• Use conditions early in the flow: if OrderId is blank, respond immediately with Succeeded = false and a friendly UserMessage instead of calling the ERP connector.
• Coalesce nulls in expressions (coalesce, empty checks) so connector actions do not throw on blank optional fields.
• For generative fill, strengthen the input description (“ISO currency code like USD”) so the model extracts correctly.

Validation checklist

1. Required fields present and non-blank
2. Types match (number parses, boolean not string)
3. Enum values in allowed set
4. String length within connector limits
5. User authorized for the operation (identity-aware design)
6. File content present when file inputs are declared

Schema drift and refresh discipline

The most common production break after a “small flow change” is schema drift:

• Input renamed or removed → BindingKeyNotFoundError / missing parameter in Call Flow
• Output renamed or removed → FlowActionException missing output from schema or response data
• Type changed → FlowActionBadRequest type evaluation errors

Resolution pattern Microsoft documents: refresh inputs/outputs on the agent; if needed, remove and re-add the flow tool so Copilot Studio reloads bindings. Always retest after rebinding.

Also watch for async response accidentally enabled—the agent may not receive outputs even when the flow run looks successful.

Worked example — order status flow contract

Business: Contoso sales agent returns live order status from a custom connector.

Flow logic: validate OrderNumber → call connector → map response → Respond to the agent with the three outputs → optionally log to Dataverse after respond.

Bad contract: single output RawJson with the entire ERP payload. That invites size limits, leaks fields, and forces the model to parse JSON unreliably.

Exam scenarios

Scenario A: Flow runs green in history, agent shows FlowActionException about missing output TicketId.
Cause: Respond action does not set TicketId, or agent schema still expects it after a rename.
Fix: Align respond outputs; refresh tool on agent.

Scenario B: Agent passes Priority as text “High”; flow declares Number.
Cause: Type mismatch → FlowActionBadRequest.
Fix: Map choice to number in topic or change flow type and all bindings consistently.

Scenario C: Maker adds new required input Region to the flow but does not update the agent.
Cause: Missing parameter in call / binding key errors.
Fix: Re-add or refresh flow tool; set binding for Region.

Parameter design checklist

1. Trigger inputs named, typed, minimized, documented.
2. Respond outputs complete, typed, user-safe messages separate from debug detail.
3. Async off; happy-path latency under 100 seconds to respond.
4. Topic and generative bindings tested with blank, wrong-type, and edge values.
5. Schema change process: edit flow → publish → refresh agent tool → publish agent → channel test.
6. Solutions package flow + agent together so parameters promote cleanly across environments.

Mastering input and output parameters turns agent flows from brittle demos into stable tools the orchestrator can call with confidence—exactly what AB-620 measures under “add input and output parameters.”