Photo by Mateusz Dach from Pexels

This time round I’m going to delve into Power Automate Desktop (PAD). PAD is a service that allows you to perform activities on a local machine as part of a flow. It’s a service that used to require an extra subscription cost, but it’s now available to everyone included with whatever tier of Power Automate you currently have.

What Can You Do With PAD?

So the big question is what can you do with Power Automate Desktop? And the answer is, quite a bit. Among the things you can do:

  • Launch and interact with desktop applications
  • Manipulate files in all kinds of ways
  • Record and replay desktop and web actions
  • Interact with the local system in a myriad number of ways such as running scripts, starting/stopping processes, printing documents, restarting the computer and so forth
  • Interact with Office documents and the clipboard
  • Send keyboard and mouse commands
  • Manipulate text
  • Use OCR to pull text from images
  • Connect to and manipulate Azure and AWS services
  • FTP interactions

That’s just the highlights. THere’s quite a bit more that you can do.

What Can’t You Do With PAD?

Power Automate Desktop does have limitations. But before we talk about that, you first need to understand how desktop flows are triggered. And you also need to understand the difference between unattended and attended modes.

Triggers

There are two ways to run desktop flows. The first is manually from the desktop. When you are logged in and Power Automate Desktop is running, you will see a little icon in the task tray to let you open the app. From there you can kick off any flow manually from the app.

Second, you can trigger the flow from Power Automate in the cloud. There is a Power Automate Desktop action that will let you pick a local machine and flow to run the same as you would any other flow action.

The one thing you can’t do is have an automated trigger on the local machine. The one thing PAD is missing is that capability to be able to set up triggers like:
When I save an image file to the pictures folder, copy it to another folder.

It would be fantastic if things like that were an option, but alas not at present.

This leads us into the next concern:

Attended vs Unattended

There are two modes in which a desktop flow can be triggered. The first is unattended mode. Unattended mode is when no one at all is logged in to the machine on which the flow is to be triggered.

In this case, when the flow is triggered, PAD will create and manage the user session, run the flow, then log the user out. The flow runs with the screen locked so anyone physically near the machine won’t see the what is running.

But there are some gotchas. First, no one can be logged in. Period. Meaning no users at all are logged in. If someone is logged in, but it isn’t the user the flow is set to run under, the flow will fail.

If anyone is logged in, but they are locked (I.e. they lock the computer and walk away), the flow will fail. If the user the flow is set to run under is logged in and working, then the flow will run in attended mode (more on that in a second)

Windows 10 desktop version cannot run multiple flows at the same time. If one flow is already running and another one tries to trigger, it will queue up additional flows based on priority and time requested.

Windows Server can run multiple flows at the same time so long as each flow is set to run under a different user and all users involved have rights to access the machine. So long as no one is logged in (same as above), then Power Automate will run as many concurrent flows as your server has ability to sign in concurrent users (based on setup and Windows Server licensing).

In all of these cases, if someone “real” tries to log in while Power Automate is running a flow, it can disrupt the flow and error out. So most of the time, you’ll want to be sure the machine running your local flows isn’t one used by people for anything else—at least at the present time.

The other mode is attended mode. To run a flow in attended mode, the user being used to run the flow must already be logged in with an active session and the session cannot be locked. If the user is not logged in or the session is locked, the flow will fail.

If a flow runs in attended mode, it is generally advisable to sit back, relax, and let the flow do its thing as interacting with the machine while the flow is running can potentially interfere with the run of the flow and cause it to fail.

Creating a Desktop Flow

So lets walk through creating a simple desktop flow and trigger it. I won’t walk through the setup process in detail. You can read more about that here: https://docs.microsoft.com/en-us/power-automate/desktop-flows/setup

The short version is you need to install three things:

  • Power Automate Desktop app – THis runs the flows
  • Browser extensions – THis allows you to interact with web apps and is available for Edge, Chrome and Firefox
  • On-premises gateway – this allows Power Automate in the cloud to trigger desktop flows on that machine.

Once you have that, creating a flow is easy. First, you’ll launch the Power Automate Desktop applicatoin and select “New flow”. Enter a name for the flow and click “Create”.

You’ll be greeted with the desktop flow designer screen. Everything is drag & drop. Along the left side you’ll see the list of available actions. Simply select an action and drag it onto the design surface. It will be automatically added to the flow and you can then provide the needed settings on the right side.

Use Cases & Conclusion

So what are some of the best use cases for Power Automate Desktop at present?

  • When you have a legacy process that can be automated, but can’t yet move into the cloud. For instance, maybe it’s part of someone’s job to run a set of batch files each day.
  • When you need to manipulate files on the local network in a certain way on a regular basis. For instance, maybe someone scans in invoices to a folder and you want a process to pick up the files, OCR them and move them into a done folder
  • Automate the printing of documents to a local printer. Perhaps someone is creating a bunch of invoices to be mailed each day and you want a process set up to print off all the generated invoices each night to be stuffed and mailed the next day.
  • Automating interaction with a legacy mainframe or system. You can automate interactions with old mainframe terminals, including reading the text, sending commands and so forth.

Basically, any time you need to do something on your local network that can’t be done from the internet. And any of us who have been around for more than a couple of years knows that there are plenty of legacy apps and processes in just about any company where these exist.

At present, in most cases, you want to use a machine no one else is using or will be logged in to in order to run your Power Automate Desktop flows. Even setting up a VM somewhere, so long as it is accessible, would work well.

It is my hope that they will overcome the limitations at some point to make it more useful on machines in active use, but I guess we’ll see what happens.