How Do You Automate Legacy Desktop Applications with Power Automate Desktop?

Detailed Explanation

Most of what Power Automate does — covered in what can you automate with Power Automate — works through connectors and APIs: a trigger fires in one system, and an action runs in another, without either system's actual screen ever being involved. That works well for modern cloud apps and anything Microsoft maintains a connector for. It doesn't work at all for a piece of software with no API — an old accounting package a business has run for fifteen years, an industry-specific desktop tool from a small vendor, or an internal application nobody has budget to rebuild.

Power Automate Desktop exists for exactly that gap. Instead of calling an API, it drives the application's visible interface directly:

1. Recording or building a sequence of UI actions — click this button, type into this field, wait for this window to appear, read the value shown in this cell — either recorded by performing the task once while Power Automate Desktop watches, or built step by step in its designer.
2. Running that sequence automatically, either attended (a person triggers it and it runs on their own machine, often while they do something else) or unattended (it runs on a schedule or trigger, typically on a dedicated machine with no person present).
3. Reading data back out of the interface — a total shown on screen, a status field, a generated confirmation number — so it can feed into the rest of a workflow, often handed off to a cloud Power Automate flow for the steps that do have a proper connector.

This is the same category of tool generally known as RPA (robotic process automation): software that operates existing applications the way a human user does, rather than integrating with them through a proper API.

When It's the Right Tool (and When It Isn't)

Genuinely the right tool for: legacy or vendor desktop software with no API and no realistic prospect of one; a task that's high-volume and repetitive enough to be worth the setup effort; an interface that's genuinely stable and unlikely to change often.

Usually not the right tool for: anything with a native Power Automate connector or a documented API — a cloud connector is faster, more reliable, and far less fragile than driving the interface, so it's always worth checking what can you automate with Power Automate's connector library first. It's also a poor fit for an application that changes its interface frequently, since every layout change risks breaking a flow built around specific screen elements — and for extremely high-volume processing, where interface-driven automation is meaningfully slower than an API call.

Things to Consider

• Confirm no API or connector exists before building an interface-driven flow. This is the single most common wasted effort in this space — teams build a fragile desktop flow for a system that actually has an underused API or an available connector, when a small amount of research upfront would have found the more reliable path. See how do you connect Power Automate to a system with no built-in connector for checking that route — a raw HTTP action or a custom connector — before reaching for desktop automation.
• Attended and unattended automation solve different problems. Attended flows help one person work faster on their own machine; unattended flows replace a person's presence entirely and typically need a dedicated machine, a service account, and a separate license — decide which one the actual use case needs before scoping it.
• Interface changes break these flows silently. A vendor update that moves a button or renames a field can make a previously working flow fail — or worse, click the wrong thing — without an obvious error. Build in verification steps (confirming an expected value appears before proceeding) rather than assuming each step succeeded.
• This pairs naturally with cloud flows, not against them. The common real-world pattern is a cloud Power Automate flow handling everything it can through connectors, and handing off to a desktop flow only for the specific step that requires driving a legacy interface — not building an entire process as one long desktop flow when parts of it have a proper connector available.

Common Mistakes

• Building an interface-driven flow for a system that already has an API. Always check for a native connector or documented API first — RPA should be the fallback for systems with no better option, not the default approach.
• Recording a flow once and never testing it against real, varied data. A flow that works on the exact screen state used during recording can fail the first time a field is empty, a dialog appears unexpectedly, or a value is longer than the recorded example.
• No verification steps between actions. Assuming each click or field entry succeeded, rather than checking for an expected result before moving to the next step, lets a flow silently continue after something has already gone wrong.
• Treating unattended automation as "set and forget." A dedicated machine running unattended flows still needs monitoring, failure alerts, and someone responsible for noticing when a flow stops working — the same silent-failure risk that applies across every tool in this cluster.