Business Central’s Bank Reconciliation Copilot Went GA in 2024. The Docs Still Call It Preview.

Finance professional reviewing bank reconciliation Copilot matches on a laptop dashboard

A client’s controller asked a straightforward question during a recent Business Central scoping call: is the bank reconciliation Copilot feature safe to turn on for month-end close, or is it still something we should treat as experimental. The honest answer took longer to give than it should have, because Microsoft’s own documentation contradicts itself on this point. The 2024 release wave 2 plan lists general availability for “Complete bank account reconciliation faster with Copilot” as October 1, 2024. The current feature page and its companion FAQ, both carrying a May 2026 update stamp, still put “(preview)” in the title. For a firm advising clients on what they can rely on inside a signed statement of work, that gap between the release-plan record and the live documentation is not a footnote. It changes what you tell a client about support commitments, change-notice expectations, and whether the feature belongs in a production close process at all.

What Bank Reconciliation Copilot Is Actually Doing

Strip away the marketing language and the feature does two distinct jobs inside the Bank Acc. Reconciliation page. First, after Business Central’s standard rule-based automatch runs and leaves a set of unmatched bank statement lines, Copilot inspects the leftovers and looks for matches the deterministic engine missed, weighing transaction dates, amounts, and free-text descriptions together rather than requiring an exact rule hit. The example Microsoft uses in its own documentation is a single lump-sum deposit that actually represents five separate customer payments; automatch sees one bank line and five ledger entries and gives up, while Copilot can propose the one-to-many match. Second, for whatever remains genuinely unmatched, a separate Copilot action suggests a general ledger account to post the difference against, based on how the transaction description compares to your chart of accounts naming. A line that reads “Fuel Stop 24” gets proposed against a Transportation or Vehicle Expense account rather than sitting in a suspense account until someone investigates it manually.

Both actions are additive, not automatic. Nothing posts until a user reviews the proposed matches and explicitly selects “Keep it,” and the G/L suggestions can be saved into the Text-to-Account Mapping table so the same vendor description resolves the same way next month without asking Copilot again. That mapping table is worth building deliberately during rollout rather than letting it accumulate ad hoc, because it is the actual long-term efficiency gain here. The AI matching helps once; the mapping table helps every month after.

The status conflict, and why it matters for how you scope this

The release-plan record and the live docs cannot both be describing the same feature in the same state, so one of two things is true. Either the GA declaration from October 2024 covered only the base matching capability, and the newer G/L suggestion and mapping workflow that shipped afterward is what the current “(preview)” label actually refers to, or Microsoft’s documentation team simply never updated the page title when the feature graduated. Nothing in the current feature page, the FAQ, or the release-plan history explicitly resolves which of those is correct, and that ambiguity is the finding worth passing to a client rather than picking one interpretation and presenting it as settled fact.

Practically, this affects two decisions. The first is whether you commit to this feature working a specific way inside a contract, since preview features in Business Central online can change behavior without the same notice period Microsoft gives to GA capabilities. The second is how you frame it to the client’s audit or SOX-adjacent controls owner, who will reasonably ask whether a “preview” label means the output is less trustworthy. It does not mean that: the matching logic runs the same way regardless of the label, and the mandatory human review step is unchanged either way. But an auditor reading the page directly will see the word “preview” before they see your explanation, so raise it first rather than let them find it.

The entry-count ceiling most rollouts hit without noticing

The feature enforces a hard scan window: it only considers open bank account ledger entries dated between one day before the earliest bank statement line and the latest bank statement line, and it caps how many open entries it will process in that window. On 2025 release wave 1 and earlier, that ceiling sits around 1,000 open entries, depending on how long the description text runs. From 2025 release wave 2 onward, Microsoft raised it to roughly 3,000. Neither number is exposed anywhere in the user interface as a running count, so the first sign a client hits it is usually a reconciliation that used to surface a dozen AI-proposed matches suddenly surfacing none, with no error message explaining why.

For a company reconciling a single operating account monthly, 1,000 to 3,000 open entries is generous headroom. For a client running high-volume accounts payable through a single bank account, or one that has let old unapplied ledger entries pile up instead of writing them off, that ceiling is closer than it looks. Two mitigations are worth building into the rollout rather than discovering during a live close: confirm the client’s release wave version before promising Copilot behavior at a specific volume, and treat unusually old open ledger entries as reconciliation debt to clean up on a schedule, not just a reporting nuisance, since they silently consume slots in that scan window every single month.

Language alignment is a real constraint, not a compliance checkbox

Microsoft’s own guidance states plainly that matching accuracy depends on the G/L account names, ledger entry descriptions, and bank transaction descriptions all being in the same language, and that mixed-language data produces measurably fewer matches and suggestions. For a domestic single-language client this is a non-issue. For a multi-entity client running a shared chart of accounts across a US and a Mexico or Canada entity, where account names might be maintained in English but transaction descriptions arrive from a bank feed in Spanish or French, this is a concrete reason the feature will underperform in exactly the entity where the manual reconciliation burden is heaviest. Check the supported-language list against each legal entity’s actual operating language before setting client expectations, not after the first disappointing reconciliation run.

What the responsible AI documentation actually commits to

The FAQ is more specific here than most feature pages get, and it is worth quoting to a nervous data governance stakeholder rather than paraphrasing. Microsoft does not use company data, prompts, or Copilot responses to train its underlying models. Prompts and responses are retained as diagnostic data for twenty days, within the same geographic and compliance boundary as the rest of the company’s data, and that retained data is accessible only to Microsoft support personnel under existing Customer Lockbox controls. Usage telemetry is anonymized and excludes the actual prompts, responses, and customer data. None of this is unusual for a Business Central Copilot feature at this point in the platform’s maturity, but it answers the two questions a client’s compliance team will ask first, and having the citation ready saves a follow-up call.

Accountant reviewing AI-suggested bank transaction matches on a laptop dashboard

A rollout sequence that avoids the common failure mode

The most common way this feature disappoints a client is not a bad match, it is silence: a reconciliation runs, nothing gets proposed, and the user assumes Copilot is broken rather than assuming they hit the entry ceiling or a language mismatch. Enable the capability through the admin center first, confirm which release wave the client’s environment is on so you know the actual entry ceiling, and run the feature against one account’s real historical statement before go-live rather than a demo company, since Business Central’s built-in demo data is tuned to succeed and will not surface any of the above limits. During that test, deliberately build out the Text-to-Account Mapping entries for the client’s recurring, easily-categorized transactions, since that mapping table is what turns a one-time AI convenience into a permanent reduction in manual coding work. Finally, document the “Post if fully applied” auto-post option as an explicit decision rather than a default: it is convenient for a fully reconciled batch, but a client with a formal month-end sign-off process may want every AI-originated posting to pass through a human approval step regardless of match confidence, and that is a control decision worth having in writing.

Close-up of a bank statement reconciliation screen with matched and unmatched transaction lines highlighted

None of this makes the feature something to avoid. Two years after its stated GA date, the underlying matching logic is mature enough that Routeget now includes it as a standard discovery item on Business Central finance engagements, specifically so the entry-count ceiling and language dependency get surfaced during design rather than during the client’s first live close. The lesson is less about this specific feature and more about a pattern that shows up across the Copilot rollout in Business Central generally: the release-plan announcement and the day-to-day product documentation do not always stay in sync, and the responsible move is to check both before you tell a client what to expect, not just the one that sounds more finished.

#BusinessCentral #BankReconciliationCopilot #ERPIntegrations #FinanceAutomation #DynamicsFinanceOps #ResponsibleAI

Same-Batch Enforcement Arrives in Dynamics 365 Production. It Doesn’t Close the Compliance Gap Alone.

Quality assurance manager reviewing a batch record on a tablet on a regulated manufacturing production line

A quality director at a mid-size nutraceutical manufacturer got a call last spring that no one wants to take: an FDA investigator, working through a customer complaint, asked for the full batch genealogy on three months of production runs. The paperwork technically existed, but tracing which raw material lots had actually gone into which finished-goods batches meant cross-referencing warehouse pick lists against production order consumption records by hand, because nothing in the ERP had stopped a warehouse worker from grabbing a partial pallet from one lot and topping it off from another when the first one ran short. That gap, mixed-batch consumption slipping past the system simply because nothing technically prevented it, is exactly what Microsoft’s new same-batch enforcement capability in Dynamics 365 Supply Chain Management was built to close. It reached general availability on September 11, 2026, as part of the 10.0.49 release, and for manufacturers operating under FDA, cGMP, or ISO quality regimes, it deserves more than a passing glance. What it actually enforces, what it still leaves to manual process, and what needs to happen internally before a CFO or quality VP approves flipping the switch are three separate questions, and they don’t all have the same answer.

How Same-Batch Enforcement Actually Works

The mechanics are narrower, and more deliberate, than the feature name suggests. Product designers and production engineers set a same-batch requirement at the released-product level, which becomes the default wherever that item shows up in a bill of materials or formula. From there, individual BOM or formula lines can override that default where a different rule genuinely applies, since not every raw material in a recipe needs the same level of control. Once that configuration is in place, the enforcement itself happens at the point production planners and warehouse staff reserve raw materials for a production order or batch order: the system restricts the available on-hand inventory to a single batch per line, rather than letting someone pull partial quantities from two or three lots to fill one requirement. Both discrete manufacturing (production orders) and process manufacturing (batch orders) are covered, which matters because a lot of regulated manufacturers run a mix of both on the same instance.

It’s worth noting the feature spent two months in public preview, from July 2026, before reaching GA in September. And “generally available” here means available through feature management, not switched on for every customer automatically. An admin, maker, or analyst still has to decide to turn it on and configure which products it applies to, which is a meaningfully different rollout posture than a change that just appears in everyone’s environment overnight.

Why This Lands Squarely on Regulated Manufacturers’ Radar

This isn’t an isolated feature. It arrived in the same 10.0.49 release where Advanced Quality Management, the suite Microsoft has been building out since version 10.0.44, became mandatory, permanent functionality rather than an optional module manufacturers could choose to skip. Advanced Quality Management is aimed squarely at pharmaceutical, food and beverage, and chemical producers operating under FDA Quality System Regulation, 21 CFR Part 11 electronic-signature requirements, current Good Manufacturing Practice, and ISO frameworks. It brings electronic batch records, corrective and preventive action tracking with e-signature closure, approved customer lists for controlling who can receive specific lots, and flexible sampling plans for quality inspection, all things an FDA or ISO auditor will ask to see evidence of during an inspection.

Same-batch enforcement fits into that picture as the piece that governs actual physical consumption rather than paperwork. An electronic batch record can faithfully document what a work order was supposed to consume, but until now, nothing stopped the gap between the documented plan and what a warehouse worker actually picked when inventory ran short mid-shift. For a CFO or operations leader, the value isn’t abstract: fewer hours spent reconstructing batch genealogy by hand during an audit or a recall investigation, and a materially lower chance that an inspector finds a discrepancy between what the system says was consumed and what physically was. Recall investigations in particular tend to be measured in days of staff time when traceability records are clean, and considerably longer when they aren’t.

What the Toggle Doesn’t Cover Yet

Here’s where the caution belongs. Microsoft’s own release documentation lists two related capabilities explicitly as future work, not part of this release: same-batch enforcement during master planning allocation, and execution validation during picking and consumption. In plain terms, that means the planning engine can still generate a supply plan today that would require splitting a raw material requirement across multiple batches, since the rule governs reservation and picking behavior rather than the planning proposal itself. It also means there’s no described hard validation step at the moment of physical pick or consumption confirmation that would catch a batch mismatch if one somehow occurred despite the reservation restriction.

None of that makes the feature not worth adopting. It does mean it should be positioned internally as one control layer added to an existing set of controls, not a replacement for the standard operating procedures, warehouse management system discipline, and internal audit sampling a regulated manufacturer already relies on. A quality team that tells its auditors “the system enforces single-batch consumption” without the caveat about planning and execution-time gaps is setting up a conversation nobody wants to have during the next inspection. The honest version of that sentence is that the system now prevents a specific, common failure mode at the reservation step, and the rest of the control environment still has to do its job.

Warehouse worker scanning a raw material batch tracking tag before reservation for a production order

What to Check Before Turning It On

A few decisions are worth working through with production and quality leadership before enabling this in a live environment, rather than leaving it as a configuration exercise for IT alone. First, the product-level default needs input from people who actually understand which raw materials carry regulatory or process risk if mixed, versus commodity inputs where enforcing single-batch picking would just add friction on the floor without a corresponding quality benefit; applying the rule everywhere by default tends to generate exactly that kind of resistance. Second, sandbox testing should specifically include the awkward cases: what happens during reservation when a single batch doesn’t have enough on-hand quantity to cover the full requirement, since Microsoft’s documentation doesn’t spell out whether that blocks the transaction outright or offers a supervised override, and that behavior will shape how disruptive the rollout feels to planners in the first few weeks.

Third, this is a change warehouse and production staff will notice immediately, since it directly limits what they can select during reservation, so it belongs on a floor communication plan before go-live rather than showing up as a surprise restriction mid-shift. Finally, quality SOPs and internal audit checklists should be updated to describe precisely where system enforcement starts and stops, so nobody overstates the control’s scope to an external auditor months from now and has to walk it back.

Same-batch enforcement is a genuinely useful, narrowly scoped addition that closes a real and specific traceability gap, arriving at a moment when Microsoft has made the broader quality management suite around it mandatory rather than optional. Its actual value to a regulated manufacturer, though, depends less on the toggle itself and more on how deliberately it gets rolled into an existing quality program. In our own implementation work with manufacturers running Dynamics 365 under FDA and ISO oversight, the configuration decisions are rarely the hard part; getting the product-level rules, the floor process changes, and the audit documentation aligned before go-live consistently is. A control that isn’t paired with the right procedure change on the ground doesn’t close the gap it was built for, it just moves where the gap sits.

#DynamicsSCM #BatchTraceability #QualityCompliance #ManufacturingCompliance #RegulatedManufacturing #SupplyChainGovernance

Power Platform Pipeline Extensibility Changes Where Your ALM Logic Actually Lives

Solution architect reviewing an abstract Power Platform pipeline deployment diagram with an approval gate on an office monitor at dusk

Every Power Platform admin who has rolled out native pipelines has run into the same wall eventually. The tool is genuinely good at the thing it was built for: letting a maker click “Deploy” and move a solution from development to test to production without learning Azure DevOps YAML or touching a service connection. What it has never let you do, until recently, is put anything of your own between that click and the deployment itself. No custom validation before export. No compliance check before the artifact lands in production. No way to route the actual deployment through a service principal instead of the requester’s own credentials. If your organization needed any of that, the answer was to abandon native pipelines and rebuild the whole thing in Azure DevOps or with the community powerplatform-actions GitHub Action, which meant losing the low-friction maker experience that was the point of adopting pipelines in the first place.

Microsoft’s new Power Platform pipeline extensibility closes that gap, and it is worth understanding closely before you turn it on, because the way it is built shapes what kinds of governance logic actually belong there versus what still belongs in your existing CI/CD stack.

What pipeline extensibility actually adds

The mechanism is Dataverse business events. Power Platform pipelines now emit a defined set of events at each stage of a deployment, and a Power Automate cloud flow sitting in the pipelines host environment can subscribe to those events using the ordinary “When an action is performed” trigger from the Dataverse connector, filtered to the Power Platform Pipelines category. There are seven distinct trigger actions you can hook: OnDeploymentRequested, OnApprovalStarted, OnApprovalCompleted, OnPreDeploymentStarted, OnPreDeploymentCompleted, OnDeploymentStarted, and OnDeploymentCompleted. OnDeploymentRequested fires for every deployment regardless of configuration, and it is also the event a pre-export validation flow hooks into. The approval and pre-deployment pairs only fire at all if you have explicitly enabled the corresponding extension on that pipeline stage, so a flow subscribed to OnPreDeploymentStarted simply never triggers on a stage that hasn’t turned that gate on.

Abstract illustration of a deployment pipeline with connected stage nodes and a glowing approval gate checkpoint

Three gated extension points sit on top of those events, and each one solves a different problem rather than being interchangeable flavors of “add a step.”

Pre-export step required

This is the earliest gate. It runs when a maker submits a deployment request, before the solution is even exported from the development environment, and Microsoft explicitly restricts it to the first stage of a pipeline. That restriction matters more than it looks: once a solution is exported, the pipelines host stores the managed and unmanaged artifacts and promotes that exact same artifact version through every downstream stage. You cannot re-validate or re-export at stage two. Whatever checks you want to run against the source solution, whether that is a naming convention audit, a check for unmanaged customizations, or a call out to an internal change-approval system, have to happen here or not at all.

Is delegated deployment

This extension solves a different problem: identity. Without it, a deployment runs under the requesting maker’s own credentials, which means that maker needs write access to the target environment, something plenty of organizations are uncomfortable granting to anyone below an admin for a production environment. With delegated deployment enabled, the actual deployment executes under a service principal instead, provided the pipeline stage owner is configured as an owner of that service principal in Microsoft Entra ID. A maker can request a production deployment, get it approved, and never hold standing access to production at all. For any organization that has been quietly working around this by granting temporary System Administrator roles before a release and revoking them after, this is the fix that was missing.

Pre-deployment step required

This is the last gate, sitting after approval but before the deployment itself actually runs. This is where a final compliance check, a change-freeze lookup, or a notification to a service desk system belongs, since by this point the deployment has already been approved and you are deciding only whether to let it proceed right now.

Wiring a flow to it

The implementation pattern is consistent across all three extension points. You build a cloud flow, in the pipelines host environment specifically, not in the source or target environment, using the Dataverse “When an action is performed” trigger. You can scope the trigger with a condition against the output parameters, most commonly DeploymentPipelineName or DeploymentStageName, so that a single environment does not end up running every organization’s validation logic against every pipeline. Inside the flow you run whatever logic you need, whether that is a call to an external API, an approval step, or a lookup against a governance table, and then you close the loop with an unbound Dataverse action: UpdatePreExportStepStatus or UpdatePreDeploymentStepStatus, setting the status to 20 for complete or 30 for rejected. A rejected status fails the deployment outright rather than leaving it hanging. Microsoft ships two sample managed solutions, Pipelines Extensibility Samples and Delegated Deployment Samples, that are worth installing into a sandbox before writing anything from scratch, since they cover the trigger and action wiring in a working state rather than leaving you to reverse-engineer the output parameter names from documentation alone.

Where this still falls short

None of this replaces a pro-code CI/CD pipeline, and it is not trying to. The GitHub Actions and Azure DevOps paths for Power Platform still own the things extend pipelines does not touch: source-controlled solution unpacking, automated build artifacts, and static analysis through the solution checker as part of a pull request gate rather than a deployment-time check. What extend pipelines is actually good at is inserting governance and identity control into the maker-facing deployment experience without forcing every citizen developer through a developer-grade toolchain. That is a narrower job, and treating it as a replacement for real CI/CD is the most common mistake I would expect teams to make with it.

The rollout itself is also worth flagging before you plan around it. As of this writing, Microsoft describes the extensibility features as being rolled out gradually across regions, and existing pipelines customers may need to update the Power Platform pipelines application through the admin center before any of these extension points even appear as configurable options. If you check a production tenant and do not see pre-export or pre-deployment settings on a pipeline stage, that is very likely a rollout or update-application issue rather than a misconfiguration on your end, and it is worth confirming with a support ticket before spending time debugging a flow that was never going to fire.

A few operational limits are worth building into your rollout plan from day one. Personal pipelines created inside make.powerapps.com cannot be extended at all, so any governance requirement has to be enforced through admin-managed pipelines rather than personal ones if extensibility is part of the plan. Makers retain the ability to cancel a pending deployment request, but only up until the final deployment step actually begins, so a long-running pre-deployment check is not a safe place to also expect cancellation to work cleanly. And because the exported artifact is immutable across all downstream stages, any pre-export validation logic needs to be strict enough to catch problems before that first export, since there is no second chance to reject the same artifact further down the pipeline.

For architects who have been asking Microsoft for a middle ground between no governance hooks at all and abandoning native pipelines for full Azure DevOps, this is that middle ground. At Routeget Technologies, this is the kind of gap our Power Platform ALM engagements have historically had to close with custom Azure DevOps pipelines, so a native option worth building a proof of concept around is a welcome addition. It is worth testing against a sandbox pipeline now, both to get ahead of the regional rollout and to work out which of the three extension points actually maps to a real control gap in your current deployment process, rather than instrumenting all three reflexively the day they become available in your tenant.

#PowerPlatformPipelines #ALMGovernance #DataverseBusinessEvents #DelegatedDeployment #PowerAutomate #EnterpriseAutomation

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