Agentic Workflows in Power Automate: When a Copilot Can Act, Not Just Report

A Copilot reads the daily production report, writes four fluent sentences about the drop in line 3 output, posts it in Teams, and a planner reads it and does what they were going to do anyway. If your OEE reporting was already daily, a generated summary changes the reading time and nothing else.

The interesting line, and the risky one, is where an agent stops describing and starts doing — raising a purchase requisition, chasing a distributor, releasing a hold.

This is about where that line sits — not in principle, but in the capability Microsoft documents today in Power Automate and Copilot Studio, and in the control layer you need underneath before any of it touches a production system.

An agentic workflow is one where an event — not a person — starts the work, and a model decides which tools to call. In Microsoft's stack that means a Copilot Studio agent with event triggers and generative orchestration, calling agent flows and connectors as tools. Three components matter, and they behave differently.

Event triggers are the real dividing line between "Copilot" and "agent": agents can be started by a SharePoint item being created, a file arriving in OneDrive, a Planner task completing, a Dataverse row changing, or a schedule — not just by a user typing. Agent flows are the deterministic part — a trigger plus actions, built so the same input produces the same output, with AI, human-in-the-loop, and built-in control actions available.

Human-in-the-loop is a first-class step: Copilot Studio supports multistage approvals in agent flows through a human-review connector, mixing manual and AI approval stages, with "first to respond" or "everyone must approve". Note that multistage approvals are in preview and do not support ALM — importing a flow means recreating the approvals, which matters if you planned to promote it dev-to-production the normal way.

Four questions, in this order. An action has to pass all four to run unattended.

Applied to industrial processes, the split is cleaner than people expect. Reasonable unattended:

• Chasing a distributor whose upload missed the cut-off, templated, with escalation after the second miss — reversible, near-zero exposure, high frequency
• Creating a task — a maintenance inspection when vibration crosses threshold, a stock-count when a variance appears. The agent creates work; a human does it
• Drafting the reply, not sending it — a supplier delay email with PO lines and dates pre-populated, sitting in drafts
• Flagging an anomaly with evidence attached — a GRN quantity that does not match the ASN — routed to the named owner
• Enriching and routing — classifying an inbound claim, attaching the invoice and POD, assigning it

Not unattended, without a human stage:

• Releasing a quality hold — irreversible in the way that matters, the stock ships
• Approving a claim or credit above a threshold — encode the threshold in the flow as a condition, not in the prompt
• Changing a price, discount or credit limit — blast radius across every later order
• Committing stock or confirming a delivery date — it creates an external promise
• Creating or amending a master record (item, vendor, outlet) — the one people underestimate

The pattern: agents are good at chasing, collating, classifying and preparing. The commitment stays human until a run history earns otherwise.

This is the part that gets skipped, and it decides whether the pilot survives contact with audit. Identity and connections: event triggers currently use the agent author's credentials only — so for an agent to run autonomously, all authenticated triggers and actions use the maker's credentials, and Microsoft warns before publishing an agent with authenticated triggers. Treat that maker account as a service identity with least privilege, not a person's everyday login.

Then: separate dev, test and production environments with connection references resolved per environment; data policies in the Power Platform admin centre as the kill switch (event triggers can be blocked organisation-wide); Dataverse auditing configured per environment; error handling with run-after, try/catch scopes, Terminate and retry policies (default four retries, exponential for transient failures); and monitoring through Copilot Studio analytics, which report run outcomes, which triggers produced the most failed runs, and tool-call success rates over a 360-day window.

Pick one loop: high frequency, low consequence, with a baseline you already have. The upload-chase loop is the one I recommend most in FMCG and distribution, because it passes all four tests and the baseline is trivially available — how many distributors submitted on time last quarter. Run the agent for six weeks and measure on-time submission rate, hours the commercial team spent chasing, and false-chase rate.

Two rules make the measurement honest. Instrument before you build — if you cannot state today's number, you cannot claim an improvement. And the credit maths matters at volume: Copilot Studio bills in Copilot Credits — 1 for a classic answer, 2 for a generative answer, 5 for an agent action, 10 for tenant-graph grounding, and 13 per 100 agent-flow actions — with prepaid capacity enforced at 125% of allocation, at which point custom agents are disabled.

Inherited permission is the real risk, not the model: autonomous triggers running on the maker's credentials mean the security review has to be of the identity, not the prompt. Silent failure is worse than loud failure — a flow that errors sends an alert; an agent that does the wrong thing confidently does not. Ungoverned data underneath makes the whole thing unsafe, which is why the sequence is unify, then predict, then act.

Two more: licensing and capacity are a live operating cost — a recurrence trigger on a short interval consumes resources continuously, and Microsoft warns frequent triggers can exceed service-load quotas. And accountability has no technical answer — when an agent releases something it should not have, the question in the room is who approved it. Preview features also move: multistage approvals are in preview and do not support ALM.

Answer these four this week, before anyone builds anything:

• Which loop happens more than 20 times a week, is a person copying information between two systems, and has never caused an incident when done slightly late?
• Whose identity would the agent run under — and list, honestly, everything that identity can currently do
• For the write action you would most like to automate: can it be reversed within one shift, by your own team, without contacting a third party?
• If that action ran wrongly 200 times overnight, what would Monday morning look like?

The fourth question decides the scope. If the answer is "we would send 200 chase emails and apologise", proceed. We build the Act layer on Power Automate and Copilot Studio — but only on top of a governed model in Microsoft Fabric, because an agent acting on ungoverned data is a faster way to be wrong. Unify, predict, then act, in that order.