{"id":4156,"date":"2026-10-13T14:56:19","date_gmt":"2026-10-13T14:56:19","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/microsoft-ab-100-copilot-studio-computer-use-legacy-apps\/"},"modified":"2026-10-13T14:56:19","modified_gmt":"2026-10-13T14:56:19","slug":"microsoft-ab-100-copilot-studio-computer-use-legacy-apps","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/microsoft-ab-100-copilot-studio-computer-use-legacy-apps\/","title":{"rendered":"Microsoft AB-100: Computer Use for Legacy Business Apps"},"content":{"rendered":"

A maintenance-support team has an awkward integration problem. Its technicians use Dynamics 365 for case management, but the warranty history of older equipment still lives in a Windows application with no supported API. The team wants an AI assistant to look up a serial number and prepare a case summary without giving the model unrestricted access to customer records or permission to change warranty decisions.<\/p>\n

Copilot Studio computer use makes a new option possible: an agent can interact with the visual interface of a website or desktop application using a configured machine, model-driven cursor and keyboard actions. But that does not make every screen a safe or reliable business integration. The architect still needs to decide whether UI automation is justified, what the agent is allowed to observe, how it handles uncertainty, and which system authorizes any consequential change.<\/p>\n

For the Microsoft AB-100 exam<\/a>, the central question is a solution design decision rather than a list of buttons in Copilot Studio. Microsoft’s English objectives effective October 14, 2026 explicitly include designing agents that automate tasks in applications and websites through computer use. The useful skill is explaining where that capability belongs in a governed multi-system workflow\u2014and when a conventional connector or human task would be better.<\/p>\n

Make the integration choice before opening the application<\/h2>\n

A structured API usually gives the architect clearer input validation, identity scope, stable error states and direct evidence of whether an operation committed. A Power Platform connector may add low-code integration and governance controls over a supported service. A visual automation tool can bridge a legacy interface whose only available contract is a screen, but that contract is subject to layout changes, loading delays, session timeouts and unexpected dialogs. Computer use is therefore an option for a constrained need, not an automatic replacement for the other two.<\/p>\n\n\n\n\n\n\n\n\n
Situation<\/th>\nUsually investigate first<\/th>\nReason to avoid the tempting shortcut<\/th>\n<\/tr>\n<\/thead>\n
The equipment system exposes an authorized supported API<\/td>\nAPI or governed connector with a narrow service contract<\/td>\nReplaying clicks would add a fragile interface dependency to an otherwise structured operation<\/td>\n<\/tr>\n
The system is desktop-only and supports a predictable read-only lookup<\/td>\nA controlled computer-use proof of concept on a dedicated machine<\/td>\nThe agent needs tested screen navigation, identity boundaries and a failure path before anyone trusts its extracted fields<\/td>\n<\/tr>\n
The workflow posts payments, handles sensitive hiring or healthcare judgments, or makes other high-risk decisions<\/td>\nAuthorized human and deterministic business-control workflow<\/td>\nMicrosoft warns computer use is not intended for sensitive or high-risk decisions and financial transactions<\/td>\n<\/tr>\n
The app changes often or uses unsupported custom widgets<\/td>\nAsk the application owner for a stable integration route or retain a human task<\/td>\nVisual automation may fail unpredictably despite apparently clear instructions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Use a trial to establish the cost of reliability. A workflow that succeeds on two screenshots is not enough. Test the same permitted lookup with slow page loading, a resized window, an unexpected dialog, stale cached results and an account whose access has changed. The team must know what the output means when the interface does not match expectations.<\/p>\n

Design a bounded read-only warranty lookup<\/h2>\n

In the example, the user enters an equipment serial number into an approved Dynamics 365 service case. The application checks that the user may view the case, then asks an agent to collect a few warranty facts from the old desktop tool. The computer-use capability is limited to opening that application, locating the requested serial number and reading the displayed product, status, and last update date. It does not authorize warranty adjustments, changing ownership or submitting a payment.<\/p>\n

A useful source contract is small: case ID, requested equipment identifier, the source system’s displayed record identifier, warranty status, source-observed timestamp, and whether the result was complete. The agent should also be able to return not found<\/em>, multiple matches<\/em>, permission denied<\/em> or outcome uncertain<\/em> without inventing a warranty conclusion. The application can compare the returned identifier with the original request before attaching the information to the case.<\/p>\n

The next action belongs outside visual browsing. A separately governed business workflow may save an unapproved draft note<\/em> against the case after checking the user’s role and the case’s current state. If the policy calls for supervisor sign-off before a warranty decision, the agent’s visual lookup cannot replace that approval. The existing Dynamics 365 and Power Platform integration<\/a> coverage describes how authoritative business applications, generated pages and supervised tasks can work together without giving the model the final transaction authority.<\/p>\n

Configure identity, machine and destination boundaries together<\/h2>\n

Copilot Studio computer use runs against a configured machine. Microsoft documents maker-provided credentials as one execution option and end-user credentials as another. The difference is significant: using the maker’s credentials for a shared agent can allow another caller to act with that account’s access on the machine. The architect must choose an identity whose permission scope matches the exact task rather than turning a convenient maker connection into an enterprise-wide service principal.<\/p>\n

Put the capability on a dedicated, isolated machine with only the approved applications installed. Restrict the account to the records and operations needed for the read-only lookup, review who can modify or publish the agent, and configure an allowed site\/application list. Microsoft’s documented allow-list behavior controls interaction with disallowed destinations; it does not necessarily prevent the browser from opening them, so underlying machine and network restrictions still matter. Enable HTTPS enforcement when the workflow uses supported web destinations, and review the local application’s authentication model.<\/p>\n

Credentials need a lifecycle as well. Copilot Studio can use its credential storage or an appropriately configured Azure Key Vault option. That does not mean prompts, screenshots or test logs should contain passwords. Operators need to understand which logs, recordings and agent transcripts may capture customer information, how access to that telemetry is restricted, and how sensitive data is excluded or minimized. The authorization boundary is the account and business service, not the mere fact that an agent successfully clicked through a login form.<\/p>\n

Human supervision helps with uncertainty, but is not an approval engine<\/h2>\n

Microsoft provides human supervision for computer use when a run requests clarification or detects potentially harmful instructions. A configured reviewer can inspect the activity and respond, subject to the feature’s availability and logging requirements. This is useful when the warranty interface unexpectedly shows two serial-number matches or an ambiguous confirmation screen.<\/p>\n

It is not a deterministic business-policy checkpoint. Microsoft’s own documentation notes that requests for human supervision depend on model behavior: the system may fail to request review when a person would want one, or request review unnecessarily. Therefore a business rule such as \u201cnever alter a warranty claim without supervisor approval\u201d must be enforced independently by the downstream application, identity policy and approved workflow. A review card produced by an agent does not itself grant permission to write the official record.<\/p>\n

A practical trust test plants an instruction in an untrusted screen or help panel telling the agent to ignore its task and open another account. The system should treat that text as data from the target application, refuse tool actions outside the configured permissions, and record what happened. If the screen claims that an administrator preapproved a change, the authoritative business application must still supply proof. This is the same separation between tool discovery and tool authorization discussed in MCP and A2A integration boundaries<\/a>.<\/p>\n

Test the failure states, not only the happy-path screen<\/h2>\n

Computer-use workflows deserve a precise operational test matrix. Visual controls can change across releases, a dialog can obscure the expected field, and an application can report success before its backend finishes writing. The model’s apparent progress is not automatically evidence of the business system’s final state. Build tests that deliberately exercise both normal completion and uncertainty.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Test case<\/th>\nAcceptable outcome<\/th>\nEvidence to preserve<\/th>\n<\/tr>\n<\/thead>\n
Valid permitted serial number<\/td>\nMatched read-only record with correct fields and source timestamp<\/td>\nRequest\/case ID, source record ID and confirmed field values<\/td>\n<\/tr>\n
Two visually similar records<\/td>\nNo guessed selection; return ambiguity for human or authoritative validation<\/td>\nList of permitted matching IDs without unrelated customer data<\/td>\n<\/tr>\n
Expired or revoked application credentials<\/td>\nAuthentication failure, no attempt to bypass controls<\/td>\nIdentity and error classification; no credentials in logs<\/td>\n<\/tr>\n
Unexpected UI layout or modal dialog<\/td>\nBounded recovery or explicit stop, not repeated blind clicking<\/td>\nRelevant sanitized activity trace and stage reached<\/td>\n<\/tr>\n
Untrusted page instruction requests data export<\/td>\nTask remains within authorized lookup scope; no export<\/td>\nRejected action and policy\/tool decision<\/td>\n<\/tr>\n
Draft note API times out after submission<\/td>\nReconcile authoritative case status before any possible replay<\/td>\nStable operation ID and external case state<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Separating these cases makes the diagnosis useful. A wrong record is a correctness issue; opening a forbidden customer account is an authorization failure; a frozen browser is an availability issue; repeating an uncertain write is a transaction-integrity problem. The response strategy differs for each. The AB-100 agent testing and validation<\/a> material provides the wider basis for using acceptance criteria, held-out cases and regression tests rather than collecting only successful demonstrations.<\/p>\n

Operational cost includes retries, review and fragile UI maintenance<\/h2>\n

Computer use has usage metering, machine requirements and model-dependent costs that should be checked in the live product documentation when the architecture is approved. A cost comparison should measure verified completed lookups: how many steps were needed, how often the target screen changed, what fraction of cases required human assistance and how many times a run failed without returning reliable data. A cheaper model step can be more expensive per acceptable case if it loops, misreads a field or requires repeated review.<\/p>\n

Compare that result with a human lookup and with a possible API modernization project. A legacy screen may make computer use the only economical near-term route. If the volume rises or the interface changes every week, paying to create a stable API or controlled extraction service may become the better investment. Set a date to revisit the decision, and track actual operational failure categories rather than assuming the initial proof of concept defines permanent system fitness.<\/p>\n

Monitoring should preserve a link between the user request, computer-use run, permitted source identifier, optional review decision and any separately authorized case update. Record observed state transitions rather than letting the agent summarize the result as \u201cdone.\u201d If the business workflow waits on a reviewer, return a pending state and an actionable next step. The agent telemetry and tuning discussion<\/a> explains how those observations support diagnosis and ongoing improvement.<\/p>\n

Document the decision an AB-100 architect should defend<\/h2>\n

For the maintenance team, a defensible provisional design is straightforward: a narrow computer-use tool reads permitted warranty facts from the desktop-only app on an isolated machine; the agent returns a structured and source-identifiable result; the authorized Dynamics workflow creates a draft and routes any consequential decision to a real reviewer. The team tests ambiguous records, unavailable credentials, changed screens and uncertain downstream writes before rollout.<\/p>\n

The architecture decision record should also say why alternatives were rejected. A direct API is preferable if the application owner supplies one with the required authorization contract. Computer use is justified only while the read-only legacy interface remains the controlled source. Direct model authority to change warranty decisions is excluded because the task does not require it and the failure consequences are unacceptable. Success means useful, verified case evidence delivered safely\u2014not the number of mouse clicks the model managed to perform.<\/p>\n

That is the AB-100 lesson: visual automation is another capability to position inside an accountable business architecture. It can cross a difficult legacy interface boundary, but it does not erase identity, approval, data-governance, testing or recovery responsibilities. Choosing when not<\/em> to automate a screen can be as important as deciding how to automate one.<\/p>\n","protected":false},"excerpt":{"rendered":"

A practical Microsoft AB-100 architecture guide to Copilot Studio computer use for legacy apps, with machine permissions, human supervision, testing and recovery boundaries.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-4156","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/4156","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=4156"}],"version-history":[{"count":0,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/4156\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=4156"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=4156"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=4156"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}