Agent Flows: Build, Monitor and Handle Errors
Create Power Automate cloud flows for Copilot Studio agents with input/output parameters, monitoring, and error handling patterns.
What Are Agent Flows?
Think of your agent as a hotel concierge. The concierge can answer questions and make small talk, but when a guest asks to book a restaurant, they pick up the phone and call the restaurant. That phone call is the agent flow.
Agent flows are Power Automate cloud flows that your Copilot Studio agent “calls” when it needs to do real work — look up data, create records, send emails, or talk to external systems. The agent handles the conversation; the flow handles the action.
The Only Trigger That Works
Every agent flow starts with the same trigger: “When an agent calls a flow.” This is non-negotiable — you cannot use “When an HTTP request is received,” scheduled triggers, or Dataverse triggers for agent-invoked flows. This trigger is what registers the flow in Copilot Studio’s action picker.
When you create a new cloud flow from within Copilot Studio, this trigger is added automatically. If you build the flow in Power Automate first, you must manually select this trigger or the flow will not appear in the agent’s action list.
Input and Output Parameters
Agent flows communicate with topics through typed parameters.
Input parameters are defined on the trigger. Each input has a name, type (Text, Number, Boolean, Object, Array), and an optional description. When the topic calls the flow, it maps topic variables to these inputs.
Output parameters are defined on the “Return value(s) to the agent” action at the end of the flow. Every production flow should return at least two outputs:
| Output | Type | Purpose |
|---|---|---|
| success | Boolean | Did the flow complete its intended task? |
| errorMessage | Text | Empty on success, descriptive message on failure |
| result | Text or Object | The actual data the agent needs to continue the conversation |
This pattern lets your topic branch on success or failure and give the user a meaningful response instead of a generic error.
Why always return success and errorMessage?
Without a success flag, the topic has no way to know if the flow failed silently. The agent would continue as if everything worked — presenting empty data or worse, incorrect data.
Returning an errorMessage lets you surface a specific, helpful message like “Could not retrieve shipment status because the carrier API is unavailable” instead of “Something went wrong.”
Exam questions often test whether you know to include explicit error signalling in flow outputs, not just the happy-path data.
Configuring Actions and Connectors
Inside an agent flow you use the same Power Automate actions and connectors as any cloud flow — Dataverse (CRUD), HTTP (external APIs), Office 365 (email, Teams), custom connectors (OpenAPI), and AI Builder (document extraction, classification).
The key difference: agent flows must complete quickly. The conversation pauses while the flow runs, so avoid long-running operations like bulk processing. Keep each flow focused on a single responsibility.
Monitoring Agent Flows
When something goes wrong — and it will — you need to know where to look.
| Feature | PA Run History | CS Analytics | Application Insights | Dataverse Audit Log |
|---|---|---|---|---|
| What it shows | Individual flow run status, inputs, outputs, step-by-step execution | Conversation-level metrics — resolution rate, escalation rate, topic usage | Custom telemetry, latency, error rates, dependency tracking | Who changed what in Dataverse tables and when |
| Best for | Debugging a specific failed flow run | Understanding overall agent effectiveness | Production performance monitoring and alerting | Compliance and change tracking |
| Granularity | Per-run, per-action detail | Aggregated across sessions | Per-request with custom dimensions | Per-record, per-field changes |
| Setup required | None — built in | None — built in | Must configure connection in Copilot Studio settings | Enable auditing in Power Platform admin centre |
| Latency | Near real-time | Up to 1 hour delay | Near real-time with streaming | Near real-time |
Error Handling Patterns
Robust agent flows anticipate failure. Five error handling patterns are available in Power Automate, and the exam expects you to know when to use each one.
| Feature | Try/Catch (Scope) | Retry Policy | Parallel Branch | Terminate | Error Output |
|---|---|---|---|---|---|
| How it works | Wrap actions in a Scope; configure a second Scope to run on failure | Set retry count and interval on individual actions | Run a fallback path alongside the primary path | Stop the flow immediately with Failed status | Return error details through the flow's output parameters |
| Best for | Catching any failure in a group of actions | Transient errors — 429 throttling, network timeouts | Providing an alternative data source or fallback logic | Unrecoverable errors where continuing would cause harm | Letting the agent topic decide how to handle the failure |
| User experience | Agent can continue with fallback response | User waits slightly longer but gets a result | User is unaware — fastest alternative wins | Agent receives failure and must handle gracefully | Agent shows a contextual error message to the user |
| Exam signal | Question mentions grouping multiple steps | Question mentions 429, throttling, or intermittent | Question mentions fallback or alternative source | Question mentions stop immediately or prevent damage | Question mentions return error to agent or meaningful message |
Exam tip: Agent flows must be synchronous
This is frequently tested. Agent flows execute synchronously — the conversation pauses until the flow completes. You cannot use async patterns like queues or webhooks within the agent flow.
For long-running operations: start the operation, return an acknowledgement, and notify the user separately when it completes.
🚚 Dev Debugs a 429 Throttling Error
Dev is building a delivery tracking agent for his logistics company. The agent calls a flow that queries a third-party carrier API to get shipment status. During peak hours the carrier API starts returning HTTP 429 (Too Many Requests) errors and customers see “I couldn’t retrieve your shipment status” messages.
Step 1: Dev opens Power Automate run history and finds the failed runs. The HTTP action shows a 429 response with a Retry-After: 30 header.
Step 2: He configures a retry policy on the HTTP action — exponential interval, 3 retries, minimum interval of 30 seconds. This handles the transient throttling automatically.
Step 3: He wraps the HTTP call in a Scope (try/catch). If all retries fail, the catch Scope sets success = false and errorMessage = "The carrier system is busy. Please try again in a few minutes." The agent now gives customers a specific, helpful message instead of a generic error.
Step 4: He checks Application Insights and finds throttling spikes between 2–4 PM — the carrier’s batch processing window.
Key Terms
Knowledge Check
Dev's delivery tracking flow calls an external carrier API that intermittently returns HTTP 429 errors during peak hours. What is the most appropriate error handling pattern?
Priya at AgentForge is building an ISV agent that calls a flow to create records in a customer's Dataverse. The flow must return data to the agent topic. Which trigger should she use?
An agent flow calls three Dataverse actions in sequence: create a case, create a task, and send a notification. If the task creation fails, the flow should skip the notification but still return an error message. What pattern should you use?
🎬 Video coming soon
Agent Flows: Build, Monitor and Handle Errors
Next up: Human-in-the-Loop Agent Flows — approval workflows, live agent transfers, and escalation patterns that keep humans in control when it matters.