If you’re on Windows and you want to automate a report download, Power Automate Desktop is the natural first thing to try. It’s free, it’s built by Microsoft, and it’s already halfway installed on most work machines. Then you open it — a canvas, a few hundred actions, a variables pane — and the report you wanted to automate is a five-click task. Two things are worth understanding before you commit an afternoon to it: how much of a build it actually is, and what it takes to make that build run on a schedule.
What Power Automate Desktop does well
Credit where it’s due, and the credit is real. Power Automate Desktop has a genuinely deep action library, handles almost any Windows or web target you point it at, and gives you a visual builder instead of a code editor. It is a serious automation platform.
That’s also the catch. A serious automation platform expects you to work like one uses it. You’ll be declaring variables, wiring up conditionals and loops, adding error handling for the run that fails at 6am with nobody watching, and choosing UI selectors that survive the site changing its layout. The visual builder means you click steps together instead of typing them out — but it’s still a build, closer to writing a small program than recording a macro. For an IT team standing up dozens of automations, that depth pays for itself. For one analyst automating one recurring download, most of that machinery is overhead you’re taking on to solve a problem that was five clicks wide.
Building the flow is the first project. Keeping it working is the second.
Even a straightforward report-download flow is a sequence of configured actions: launch a browser instance, navigate, wait for an element, handle the login, click through, capture the file — each with its own parameters to get right. Miss one selector and the flow hangs or fails without telling you much about why. And UI automation is brittle by nature: when the report site adjusts its layout, the flow breaks, and you’re back in the builder working out which action stopped matching. It’s maintainable. Maintaining it is now a standing item on your to-do list.
Where it gets harder: running it unattended
The moment you want a flow to run on a schedule, without a person present, the requirements change. Per Microsoft’s own documentation, unattended desktop flows require a Power Automate Process license or an Unattended RPA add-on assigned to the machine — and that machine first has to be registered by a Power Automate Premium user. The free tier that got you this far doesn’t cover the thing you actually wanted.
There’s a second constraint that catches people off guard: a Windows 10 or 11 machine can’t run an unattended desktop flow if any Windows user session is active — even a locked one. All users have to be signed out completely, and logging into the machine while an unattended flow runs can make it fail. In practice, you need a machine that nobody is logged into, sitting available for the flow to take over.
What that adds up to for one analyst
On top of the flow you had to build and now have to maintain, the unattended path asks you to line up three things that usually aren’t yours to hand out:
- A paid license — Process or Unattended add-on — which is a procurement conversation, not a checkbox.
- A Premium user to register the runtime machine — normally someone on an IT or Power Platform team.
- A machine with no active user sessions — not your laptop, which you’re signed into all day.
None of that is unreasonable for an organization running RPA at scale across a department. It’s a lot of assembly for one person automating one report — and it’s often the exact reason the report isn’t automated yet.
How Report Flow handles the same job
Report Flow is narrower on purpose. It automates browser workflows — report downloads, portal exports, anything behind a login and a download button — rather than being a general Windows automation platform. For that specific job:
- You don’t build a flow. You record yourself doing the task once — clicks, fields, navigation, login included — and Report Flow replays it. There are no variables to declare, no error-handling branches to design, no selectors to choose by hand.
- When the site changes, you fix one step. The run log points at the step that broke, so you edit that step or re-record that portion — you’re not tracing a failure through a flow diagram.
- Scheduling is a flat paid feature, not an infrastructure project. It starts on the Solo plan at $49/month. Turning it on takes a flat monthly price — no add-on SKU, no admin-registered machine, no requirement that the machine have zero logged-in users.
- It runs on the machine you already use. An opt-in Always-on mode keeps scheduled workflows running after you log off, and asks Windows to wake the machine for each run on hardware that supports it.
When Power Automate Desktop is still the right choice
If your organization is already invested in the Power Platform — the licenses exist, there’s an RPA team, adding one more flow to a managed environment is routine — Power Automate Desktop is the better-integrated option, and the math works out differently at that scale. It’s also the right call if you only ever need attended automation: the free tier genuinely covers “click the button, watch it run,” and there’s no reason to pay for anything else.
Report Flow is built for the other case: you need one browser workflow to run on a schedule, you don’t have an RPA team or a spare machine, and you’d rather record the task than build it.
Side by side
| Report Flow | Power Automate Desktop | |
|---|---|---|
| Building the automation | Record the task once | Configure a multi-action flow — variables, waits, error handling |
| Attended (manual) automation | Free plan (2 workflows) | Free on Windows 10/11 |
| Scheduled / unattended runs | Solo plan, $49/mo | Process license or Unattended RPA add-on |
| Machine setup for unattended | Runs on your normal machine | Machine registered by a Premium user; no active user sessions allowed |
| Survives logoff | Opt-in Always-on mode | Requires a dedicated always-signed-out machine |
| When the site changes | Fix the one step the log flags | Debug the flow to find the broken action |
| SSO / session-based logins | Recorded as part of the workflow | Not handled natively; needs UI-level workarounds |