Copilot Studio’s Computer-Use Agents Reached GA. The Success Rate Numbers Change the Business Case.

IT director reviewing an automated workflow diagram representing a Copilot Studio computer-use agent on an office monitor

A mid-market distributor recently asked its systems integrator for a quote to build an API bridge between Dynamics 365 Finance and Supply Chain Management and a fifteen-year-old carrier portal that still runs on a browser-only interface with no exposed endpoints. The estimate came back at nine weeks and roughly $160,000, most of it spent reverse-engineering a login flow and a rate-lookup screen that changes its layout every few months. That is the exact situation Copilot Studio’s computer-use agents were built for, and as of May 2026 the capability is generally available rather than sitting in preview. For CIOs and finance leaders staring down a similar quote, the real question is not whether the technology works. It is whether it works well enough, cheaply enough, and safely enough to replace a project that would otherwise sit on the backlog for a year.

What Copilot Studio’s computer-use agents actually shipped at GA

Computer-use agents let a Copilot Studio agent operate a website or a Windows desktop application the way a person would: it takes a screenshot, reasons about what it sees, and performs a click, a keystroke, or a scroll toward a stated goal. Microsoft’s own release announcement frames the GA milestone around three changes from the preview period. Credential handling moved to a more secure model rather than embedding logins in flow definitions. Customers can now choose which underlying model drives the automation, matching cost and capability to the task instead of accepting a single default. And the agents became noticeably more resilient to interface drift, meaning a carrier portal that shuffles a form field or repositions a button is less likely to break the automation outright, which was one of the most common failure modes reported during preview.

The feature also picked up a genuinely useful architectural change: computer-use steps can now be embedded inside a broader workflow, so a single process can call an API where one exists, fall back to UI automation where it does not, and route to a human approver for anything in between. That matters more than it sounds. Most legacy integration problems are not purely API-less. They are mixed: part of the process has a clean endpoint, and the rest lives behind a login screen nobody ever modernized. Treating the whole thing as one workflow, rather than stitching together a separate RPA tool alongside your Power Automate flows, is the actual value proposition here, not the novelty of an AI agent clicking buttons.

Where the economics genuinely hold up

Computer-use agents consume Copilot Credits on a per-step, consumption-based model that behaves differently from the message-based billing most finance teams are used to budgeting for a chatbot or a Copilot assistant. A short, well-scoped task, four or five steps to submit a form and confirm a result, costs relatively little. A long, branching process with dozens of steps run at volume compounds that cost quickly, and it compounds faster than most stakeholders expect the first time they see a monthly bill next to the pilot’s success metrics. Before approving a production rollout, finance and IT should jointly model the cost of the highest-volume scenario at expected transaction counts, not just the demo scenario that sold the project internally.

The honest framing for a CFO is this: computer use is not a general substitute for API integration. It is a tool for the specific and fairly common case where an API genuinely does not exist, the vendor has no near-term plan to build one, and the manual alternative already costs real headcount hours. A carrier rate portal, a government filing site, an old third-party benefits administrator, or an internal legacy application from a prior ERP era are the kinds of targets where the math works. Where an API does exist, even a mediocre one, direct integration through Power Automate or a custom connector will almost always be cheaper per transaction than UI automation, because every additional screenshot and reasoning step adds cost that a direct API call skips entirely. Teams that reach for computer use as a default integration pattern rather than a fallback tend to discover this the expensive way, usually around the second or third month of production volume.

Abstract illustration of an AI agent cursor navigating connected software interface panels

The success-rate numbers that should set expectations

Microsoft’s own documentation is candid about current performance limits, and CIOs evaluating this for anything beyond a narrow pilot should read those numbers before committing a budget line. Web-based tasks succeed at roughly 80 percent, which sounds reasonable until you consider what a one-in-five failure rate means for a process running hundreds of times a day. Desktop application tasks succeed at closer to 35 percent, a gap wide enough that any deployment targeting a legacy Windows client, rather than a browser, should be scoped as an assisted process with human review built in from day one, not a lights-out automation. Dropdowns, date pickers, and custom UI widgets remain a known weak point, along with the tendency for an agent to loop when the screen state does not match what it expected.

None of this makes the technology unusable. It makes it a tool that needs the same production discipline any automation project requires: define what “success” means precisely, measure it against a real baseline rather than a demo, and build an escalation path for the failures you know are coming rather than treating them as edge cases to handle later. Microsoft’s own guidance recommends exactly this, pointing customers toward least-privilege service accounts, restricted execution environments, and human-in-the-loop review for lower-confidence steps as standard practice rather than optional hardening.

Governance decisions to make before the first production run

Three controls matter most for a finance or IT leader signing off on this. First, audit logging: computer-use sessions can send activity to Microsoft Purview under a dedicated operation type, independent of the standard Dataverse logs the agent keeps by default, and that Purview trail is what most compliance teams will want to see before approving a process that touches financial data or customer information. Second, session visibility: every run generates a step-by-step activity map with screenshots, timestamps, and a list of exactly which credentials and which sites or applications were accessed, which gives an auditor something concrete to review rather than a black box. Third, and easy to overlook, the allow-list that restricts which sites an agent can act on does not fully prevent navigation to sites outside that list, only actions on non-allow-listed pages. Organizations with strict data-boundary requirements should layer network-level controls, such as browser policies through Microsoft Intune, on top of the Copilot Studio allow-list rather than treating the allow-list as a complete boundary on its own.

Administrators who decide the risk profile is not yet acceptable for a given environment can disable computer use entirely at the environment level, or disable the hosted browser specifically at the tenant level, through the Power Platform admin center. That toggle is worth knowing about even for organizations planning to adopt the feature, since it gives a clean way to pilot in one environment while keeping it off everywhere else until the governance model is proven.

What this means for the next integration decision

The distributor with the fifteen-year-old carrier portal does not need to choose between a $160,000 custom build and doing nothing. A scoped computer-use pilot against that single portal, with success measured honestly against the current 80 percent web success rate and a human reviewer catching the rest, is a legitimate middle option that did not exist eighteen months ago. The mistake would be extending that same logic to every integration gap on the roadmap without first checking whether each one is genuinely API-less or just under-prioritized. For organizations already running Dynamics 365 Finance and Supply Chain Management or Business Central alongside a Power Platform footprint, the practical next step is an inventory: which manual, screen-based processes actually lack an API path, which have one nobody built yet, and which are high-enough volume that the per-step credit cost changes the calculation entirely. Routeget Technologies has been walking clients through exactly that kind of inventory as computer-use agents move from a curiosity into a line item finance actually has to approve, and the pattern holds across industries: the technology is real, the cost model rewards precision over enthusiasm, and the governance controls exist, but only for the teams who turn them on before the first production run rather than after an incident.

#CopilotStudio #ComputerUseAgents #AgenticAI #RPAGovernance #EnterpriseAutomation #DynamicsFinanceOps

Power Automate’s Desktop Flow Version Control Reached GA. It Isn’t the Git Workflow You Expected.

Solution architect reviewing a workflow version comparison on a monitor in a modern office

Last quarter, a client’s unattended invoice-processing bot broke in production after a maker “fixed” a selector on a Friday afternoon and republished without telling anyone. There was no way to see what had changed, no way to diff the working version against the broken one, and no way to roll back except by rebuilding the flow from a screenshot someone had taken three weeks earlier. That is not a hypothetical: it is the normal operating condition for most Power Automate desktop flow estates, and it is the exact gap Microsoft’s new desktop flow version control feature was built to close.

Desktop flow version control reached general availability on May 13, 2026, alongside a companion capability, compare flow versions, released the same day. A related feature, test subflows with test suite, followed in June 2026. Together they represent the most significant governance shift Power Automate for desktop has had since unattended runs first shipped, and for solution architects who have spent years explaining to security and change-management teams why their RPA estate has none of the source-control discipline their .NET or Java pipelines take for granted, this is worth understanding in detail, not just filing away as a changelog entry.

What Desktop Flow Version Control Actually Shipped, and What It Isn’t

The instinct when you hear “version control for desktop flows” is to picture Git: branches, merges, pull requests, a commit graph. That is not what Microsoft built, and treating it as a Git replacement will set you up for a bad rollout conversation with your development team. The underlying storage is Dataverse, not a distributed version-control system. Every draft and published version of a desktop flow is stored there in a compressed format, and Microsoft’s documentation is explicit that there is no configurable cap on how many versions accumulate, though versions older than twelve months are automatically purged, with the exception of the latest published version, which is retained indefinitely.

The model itself is linear rather than branching. A maker saves incremental changes as a draft, which has no effect on whatever is currently running in production. When the maker is satisfied, they publish, which creates an official version available for execution from the console or from a triggering cloud flow. Publish is deliberately disabled until the flow contains at least one enabled action, a small guardrail against accidentally shipping an empty shell. Every prior published version remains accessible as a read-only, previously-published entry, and a maker can restore any of those older versions, which pulls it back in as the current draft rather than silently reinstating it as production. That distinction matters operationally: restoring a version is a deliberate, two-step act, not a one-click rollback that could be triggered by accident.

There is no merge conflict resolution because there is no merging. If two makers edit the same flow concurrently, Microsoft’s guidance is essentially to coordinate manually and avoid overlapping edits, which is a meaningfully different discipline than what a development team accustomed to feature branches will expect. If your organization runs a centralized Center of Excellence model where a small number of makers own each flow, this limitation is mostly academic. If you have distributed ownership across multiple business units touching shared subflows, it is a real constraint you need to design around before you tell anyone this “solves” your governance problem.

Compare Flow Versions: What the Diff Actually Shows

The comparison tool is where this feature starts to feel like genuine engineering tooling rather than a glorified undo button. Selecting any two saved versions opens a read-only comparison view, with the designer locked from editing while the comparison window is open, and the most recent version by timestamp used as the reference baseline. The right-hand pane acts as a change filter: clicking an entry highlights the corresponding element directly in the flow canvas, so you are not scrolling through the whole flow trying to spot what moved.

The scope of what gets diffed is broader than a simple action-by-action list. It surfaces added, removed, and renamed subflows; changes to action configuration and parameters; variable type, name, and value changes; updates to UI element selectors, which is precisely the category of change that silently breaks unattended runs most often; and additions or removals of image assets used for image-based automation. For a team that has ever spent an afternoon trying to figure out why a previously stable flow started failing, having selector changes surface explicitly in a diff view is arguably the single most practically useful part of this release, more so than version control’s headline framing suggests.

Abstract illustration of workflow nodes with a version comparison branch and a passed test checkmark

Subflow-Level Testing Closes a Real Gap

Before this release, testing a Power Automate desktop flow meant running the entire parent flow end to end, because there was no supported way to validate a subflow’s logic in isolation. That forced teams into a familiar bad pattern: either skip meaningful pre-deployment testing because a full run is slow and environment-dependent, or build brittle manual test scripts outside the platform entirely. Test subflows with test suite, which reached general availability in June 2026, extends the existing desktop-flow test framework down to the subflow level, using the same behavior-driven-development structure, defined inputs, expected outputs, and assertions, that the parent-flow test suite already used.

This is not glamorous, but it is the piece that actually makes version control operationally useful rather than just a historical record. A version history without a way to verify that a candidate version behaves correctly before you publish it is an audit trail, not a quality gate. With subflow-level tests, a maker can validate the specific piece of logic they changed, independent of the surrounding flow, and get a pass or fail result recorded in the console and designer before that version ever reaches an unattended runtime. Combined with the comparison tool, you now have a workflow that resembles, even if it doesn’t literally replicate, a real pre-merge review: see exactly what changed, run a targeted test against the changed logic, then publish deliberately.

The Caveats That Change Your Rollout Plan

A handful of details in Microsoft’s documentation will change how you deploy this, and skipping them is how a promising governance feature turns into a support ticket. Self-healing, the capability that lets a desktop flow automatically repair a broken UI selector at runtime, is disabled whenever a flow is running from a saved draft rather than a published version. If your team gets in the habit of testing directly against drafts in a production-adjacent environment, understand that you have also quietly turned off a reliability feature you may be depending on elsewhere.

Enabling the feature requires the prvReadcomponentchangesetpayload privilege, which is included by default for the Environment Maker role but must be added explicitly to any custom security role your organization uses for minimum-permission configurations, a step that is easy to miss if your RPA governance model already deviates from Microsoft’s defaults. Import conflicts are another real-world snag: importing a published flow into an environment that already has an unpublished draft throws an error about an unmodified active context with an existing unpublished row, and the fix is to delete the pending draft before the import runs, which has implications for how you structure ALM pipelines that move flows between dev, test, and production environments. Finally, once version control is turned on for an environment, it cannot be turned off, which argues for enabling it first in a genuinely lower, disposable sandbox rather than directly in whatever environment your team currently treats as “dev.”

What This Means for How You Structure RPA Delivery

None of this makes desktop flow governance equivalent to modern application development practice, and it shouldn’t be sold to a client or an internal stakeholder that way. But it does close the two gaps that have made RPA estates genuinely hard to govern at scale: an unauditable history of what changed and when, and no supported way to test a piece of logic before it reaches an unattended machine. Teams that adopt both capabilities together, disciplined draft-and-publish habits paired with subflow tests run before every publish, will get a meaningfully more defensible answer the next time an auditor or a CISO asks how changes to an automation that touches financial or customer data actually get reviewed. Teams that enable version control and stop there, treating it as a rollback insurance policy rather than a discipline, will find it useful during an incident and largely irrelevant the rest of the time.

Routeget Technologies has been building governance frameworks around Power Automate and Power Platform estates for clients moving from pilot-stage RPA into production-scale automation, and the pattern above, comparison-driven review paired with subflow testing before publish, is close to what we now recommend as a baseline practice rather than an aspirational one. The tooling finally supports it; the discipline still has to be built deliberately.

#PowerAutomate #DesktopFlows #RPAGovernance #ALM #ProcessAutomation #EnterpriseAutomation

Power Automate’s Self-Healing Desktop Flows: What Gets Fixed, and What Still Breaks

IT operations engineer monitoring automated workflow dashboards on multiple monitors

A desktop flow that has run clean for eight months can start failing on a Tuesday morning for reasons that have nothing to do with the flow itself. A vendor portal repaints its login page during a routine update, a button that used to sit at a fixed set of pixel coordinates shifts three rows down, and the automation that finance has relied on for month-end reconciliation throws “Element not found” at 6 a.m. with nobody watching. This is the specific kind of fragility that Power Automate’s newly introduced self-healing desktop flows capability is built to reduce, and it is worth understanding precisely what the feature does before assuming it solves a problem it was never designed to solve.

IT operations engineer monitoring automated workflow dashboards on multiple monitors

Why UI Automation Breaks in the First Place

Desktop flows built around UI and browser automation actions work by capturing a selector, essentially a description of where an element lives inside an application’s structure, and replaying that description at runtime to find the same button, field, or menu again. That approach has always been reliable right up until the moment it isn’t. A web app ships a design refresh. A desktop application renames a control during a patch. A browser update changes how a page renders just enough that the original selector no longer resolves to anything. None of these changes touch the business logic of the flow at all, yet they are historically among the most common reasons a production RPA process stops overnight. They are also the reason RPA teams spend a disproportionate share of their maintenance time on selector repair rather than on building anything new.

What Self-Healing Desktop Flows Actually Do

Self-healing entered public preview on March 31, 2026, as an agentic capability scoped specifically to UI and web automation actions inside Power Automate for desktop, version 2.66 and later. It is not a general reliability feature, and it does not run continuously in the background. It activates only at the moment a specific action throws an Element not found error on the primary or secondary screen, or a Window not found error on the main screen, and only for actions involving a single UI element interaction such as a click or a checkbox selection.

When that failure occurs, the flow’s existing retry policy still runs first. Self-healing sits as a fallback step after retries are exhausted and before whatever error handling rules a maker has configured downstream, things like setting a variable or running a subflow. At that point, the desktop flow captures a screenshot of the missing element’s expected location, the parent window’s title, and a full image of the desktop, then passes that context to two large language models working in combination: GPT-4.1 mini and Claude Sonnet 4.5. The models attempt to identify a UI element that plausibly matches what the original selector was looking for, propose it as a substitute, and let the flow continue. If neither model can produce a confident match, the flow falls through to normal error handling exactly as if self-healing were not enabled at all.

That single design choice, using self-healing purely as a recovery mechanism rather than a permanent correction, matters more than it might first appear. The feature does not rewrite the flow’s stored selector once it recovers. Every future run of that same action will hit the same missing-element error and go through the same self-healing detour again, which means self-healing reduces the visible symptom of a broken selector without eliminating the underlying maintenance debt sitting behind it.

Where the Coverage Actually Stops

Teams evaluating this feature tend to assume it covers more ground than it does, and the gaps are specific enough to matter for planning. Self-healing does not apply to window or screen handling actions, so a flow that fails because an entire application window can’t be located, rather than a single control inside it, gets no help here. It does not extend to multi-element interactions like drag-and-drop, which remain exactly as brittle as before. It has no effect during designer test runs, applying only to console and cloud runs in attended or unattended mode, so a maker debugging inside the desktop flow designer won’t see it engage at all. And because the underlying models work from a screenshot and a window title rather than the application’s actual DOM or object model, self-healing is inherently probabilistic. Microsoft’s own documentation is direct about this: the models can occasionally identify the wrong element, which for a click action on a financial approval screen is not a theoretical risk worth shrugging off.

Close-up of a laptop screen showing a workflow diagram with one error node highlighted

There is also a visibility gap worth planning around before rollout rather than discovering during an incident. The Power Automate portal does not currently surface self-healing activity inside standard action-level run logs. The desktop flow run page shows a rollup of up to three successful self-healing attempts, but anyone who wants a full audit trail has to fall back to a registry setting that writes a repairWithAIInfo property into local log files on the machine running the flow. That is a meaningfully more manual process than most teams are used to for production RPA monitoring, and it is worth building into a rollout checklist rather than assuming the standard portal view will show everything.

Turning It On

Enabling self-healing is not a single toggle, and the chain of prerequisites is easy to get partway through and assume is finished. It starts in the Microsoft 365 admin center, under Copilot settings, where Anthropic has to be enabled as an approved AI subprocessor. This is already the default for most commercial cloud tenants, but it is worth confirming rather than assuming, especially in regulated environments where subprocessor lists get reviewed on a fixed schedule. From there, the same approval has to be granted a second time inside the Power Platform admin center, under Copilot settings, where external models are configured at either the environment or environment group level. A tenant using non-US regions also needs to explicitly allow data to move across regions under that environment’s generative AI features, since the underlying model calls are not necessarily processed in-region otherwise. Only after those three settings are in place does a fourth toggle, Copilot in Power Automate under the same admin settings, need to be switched on before the capability becomes available to makers at all.

At the flow level, the configuration is much simpler by comparison. Inside the desktop flow designer, a maker opens the error handling settings on a supported UI or web automation action and switches on self-healing for that specific action, one action at a time rather than as a flow-wide setting. This granularity is a genuine advantage for a phased rollout. A team can enable self-healing selectively on the handful of actions in a flow that interact with the least stable third-party interfaces, such as a vendor portal outside the organization’s control, while leaving internal, well-governed applications on standard error handling until there is a clearer track record to point to.

Fitting This Into an Error-Handling Strategy, Not Replacing One

The practical risk with a feature like this is not that it fails to work as documented. It is that a maker treats a preview capability with known gaps as a substitute for the selector discipline, monitoring, and testing that RPA has always required, and quietly stops doing that harder work because the flow appears to keep running. The teams getting real value from self-healing so far are treating it as one layer in a broader error-handling stack, sitting below a solid retry policy and above a documented escalation path, rather than as the whole strategy. That means still designing selectors deliberately instead of accepting whatever the recorder captures by default, still monitoring flow run history instead of assuming silence means success, and still budgeting time for the registry-level log review needed to catch a self-healing attempt that quietly picked the wrong element on a screen nobody double-checked afterward.

Used that way, self-healing does what its name suggests for a specific and fairly narrow category of failure: it buys time and reduces the volume of after-hours pages caused by a button that moved six pixels to the left. It does not, and by Microsoft’s own account is not meant to, remove the need for an RPA program that treats maintenance as part of the design rather than an afterthought to it. Routeget Technologies has been walking clients through exactly this kind of phased rollout, piloting self-healing on the least stable external-facing actions in a flow before deciding how far to extend it. That sequencing, more than the feature itself, is usually what determines whether a preview capability like this earns a permanent place in production.

#PowerAutomate #SelfHealingFlows #DesktopFlows #RPAGovernance #PowerPlatform #AutomationReliability