Copilot Studio Computer Use: Setup and Review

Copilot Studio agents can interact with desktop applications and web browsers through Power Automate Desktop, a robotic process automation (RPA) tool that records and replays UI actions. This lets an agent complete tasks in legacy systems, internal tools, and any application that has no available API.

Because computer use involves acting on real systems with real data, the boundaries for what an agent is allowed to do need to be explicit and recorded. Tools like fenbs keep those boundaries as Decisions that any connected assistant reads before starting a session, which means the rules travel with the project rather than living only in the person who set them up.

What computer use means in Copilot Studio

Computer use in the Copilot Studio context means a Copilot Studio agent calling a Power Automate Desktop flow that performs UI automation. The desktop flow controls a keyboard and mouse on a Windows machine, opening applications, clicking buttons, reading screen content, and entering data. The Copilot Studio agent decides when to trigger the flow and what data to pass to it.

This is different from a browser-based connector. A connector calls an API and receives structured data. A desktop flow interacts with the visual interface of an application, which makes it more fragile when the interface changes but applicable to systems that offer no API at all.

Prerequisites and infrastructure

Running a desktop flow requires a machine with Power Automate Desktop installed and the machine registered in the Power Platform admin center. The machine must be running and accessible when the flow is triggered. For production use, this typically means a dedicated machine or virtual machine rather than a developer's laptop.

The Copilot Studio agent itself runs in the cloud. It calls the desktop flow by passing data to it. The desktop flow runs on the registered machine and returns results. Latency between the two is a factor in how responsive the assistant feels during a computer-use task.

Managing credentials for desktop automation

Most desktop automations require logging into an application. Power Automate Desktop supports credential management through Azure Key Vault and the Power Platform credential management service. Credentials stored this way are referenced by name in the desktop flow rather than embedded in the script.

Never embed a password directly in a desktop flow script. Anyone with access to the flow can export it. Store credentials in Key Vault and reference them through a connection reference. Rotate credentials on the same schedule your organization uses for other service accounts.

Defining what the agent is allowed to do

A computer-use agent can, in principle, do anything a human user can do on the registered machine. That scope is too broad for a production deployment. Before you connect the agent to a desktop flow, write down the specific tasks it is allowed to perform and the data it is allowed to read and write.

Common approved tasks include: reading a record from a legacy system and returning it to the user, submitting a standard form with data the user provides, and extracting a report that is not available through an API. Common tasks that belong behind a human approval: writing a record to a financial system, sending a communication on behalf of a user, or taking an action that cannot be reversed.

Testing before production

Test desktop flows in a non-production environment first. Use a test application or a copy of the production system with non-critical data. Verify that the flow handles the target application's loading time, that it finds the right elements when the screen is at different resolutions, and that it recovers cleanly when an element is not found.

Run failure path tests: what happens when the target application is not running? What happens when the record being read does not exist? A flow that errors silently and returns an empty result is harder to debug than one that returns a clear error message.

Where human review belongs

Build a review step into any computer-use flow that writes data to a system of record. Use Power Automate's approval action to pause the flow until a person confirms the data before the write happens. For read-only tasks, review is optional but useful during the first weeks of a new flow.

Log each desktop flow run with its input data and outcome. When something goes wrong in production, the run history is how you establish what the agent did and in what order. Keep that log accessible to the team responsible for the system the agent writes to.

How to do this with fenbs

Use fenbs to record the approved boundaries and track issues that need human review before the flow can handle them.

1. Create a free account and add a project for the computer-use automation.
2. Add a task for each desktop flow in scope. Note the target application, the actions the flow performs, and the data it reads and writes.
3. Record each approved action and each forbidden action as a Decision in fenbs. Link them to the flow task so the context is in one place.
4. When testing reveals an edge case the flow cannot handle cleanly, add it as a task. Do not deploy until the edge case is either handled or explicitly deferred with a recorded reason.
5. Save progress before the review meeting: what the flow does, what was tested, what the known limitations are, and who needs to sign off before production.

fenbs does not monitor desktop flow runs or alert you to errors. Use Power Automate's run history and alerting for that. fenbs keeps the approval decisions and the open issues in one record.