RPA Is a Two-Way Street
Power Automate Desktop Wait Actions
Power Automate Desktop (PAD) is a branch of Power Automate and its purpose is to accomplish Robotic Process Automation (RPA), the function of software to automatically simulate human actions on a user interface. You will read the terms “flow” and “automation” in this article, and they mean the same thing unless explicitly acknowledged otherwise.
When first diving into Robotic Process Automation as a developer, it can be easy to get hung up on the desired outcome of an RPA process and not focus on the minutia of each step. When building single-purpose flows for oneself, this line of thought mostly works fine.
Microsoft has defined single-purpose flows as a core intended usage Power Automate Desktop (PAD); this is also why PAD is now being put on every user computer using the Windows Operating System. All Windows users are now free to make small automations and accomplish personal tasks with attended automations.
Where this logic starts to falter, though, is with unattended, variable, or high-volume automations. With attended flows, users can watch a screen accomplish tasks as they do them. This makes many greener developers (like me at one point) start to treat RPA flows as player pianos: give PAD a list of instructions and PAD will sequentially follow them.
Why isn’t it this simple then? If you’ve ever developed a production-tier, enterprise-grade flow, you know how much more work it takes than that. To ensure stability in unattended and high-volume flows we need dynamism. We need the flow to be able to go faster or slower, or make additional decisions based on a myriad of reasons: network latency, request volume, every piece of technology having its own variances, intermittent pop-ups, general performance, and much more.
The Two-Way Street of RPA
Enterprise RPA flows aren’t simple because RPA is a two-way street. One way of this street is RPA software providing a device inputs, and the other way of this street is RPA software ingesting a device’s outputs. Based on those outputs, RPA software should be able to adjust its behavior if needed. It’s easy to take ourselves for granted when operating a computer, but computers wouldn’t need monitors if humans didn’t need to observe the outputs on computer monitors. As we’ve demonstrated the equal importance of both device inputs and device outputs, RPA developers also need to think thoroughly not only about providing Power Automate Desktop flows with proper inputs, but how they will allow PAD to ingest the computer’s outputs.
The Human Experience of Routine Changes
Put yourself in a scenario where you sit down at your PC at the beginning of a workday. Nothing particularly unique is on the docket for today, and for at least the next 15 minutes you are just going to get the necessary processes started on your computer: you sign in, you open and read through Outlook, you update your timesheet from the prior day, and you start up a couple pieces of legacy software. In your brain, you’re practically operating off muscle memory.
From here, four unique occurrences happen:
All the occurrences mentioned above, to a human user, might not even be noticed when moving through them. You’ve changed your password on every service you’ve used your whole life. You take a longer sip of coffee than usual while waiting on Outlook. The changes to your timesheet provider were all aesthetic and didn’t affect the general process of entering time. You click the back button on the legacy software and you’re exactly where you need to be.
Handling Unique Occurrences with Wait Actions
All four of the marked occurrences described above would break an RPA flow if not accounted for. How we account for unique occurrences like these is by tracking the outputs they provide to the end screen. Outputs are ingested primarily in PAD through “Wait” actions. There are lots of different types of Wait actions and almost all of them can be considered to ingest outputs. Wait actions can ingest processes being ready to use or completed, files to have a certain status, images to appear on a screen, and much more. If you think about it, these are all the same indicators we use to interact with technology daily.
Visual of all the Wait actions in Power Automate Desktop
This image shows all the Wait actions in Power Automate Desktop. Let’s look at how we could use some of these in our earlier example.
Adding Wait actions into your flows, especially enterprise and unattended flows, will drastically improve the reliability for your automations in Power Automate Desktop. This is because it will also allow your flows to make different decisions based on what happened in this specific run, as well as moving through those decisions faster or slower.
This becomes even more apparent in the case of unattended flows, where a user interface is technically being used, but not be seen by the user. In an unattended context, PAD needs the ability to autonomously make decisions more than ever, and using a diverse set of Wait actions early and often is what will allow you to do that.
If we, as developers, expect our RPA flows to interact with a computer as effectively as we do, we need to provide those RPA flows with the same context we use when interacting with a computer. This means not only giving RPA flows the one-way street of properly configured inputs but also enabling the two-way street of both providing inputs and ingesting outputs.
P.S. It is important to note that there is one Wait action that doesn’t ingest outputs, and that is the most basic Wait action at the top of the list. This is because waiting an arbitrary amount of time is not ingesting a computer’s output. It is making a bet that a computer will accomplish an action in that amount of time, and there always looms the very real possibility that the previous action finished much sooner or (much worse) didn’t finish at all, and the flow fails. Retries and loops will only solve this problem if the action eventually can succeed in the static amount of time you provided the step in PAD, so retries and loops wouldn’t guarantee anything either. Use the basic Wait action sparingly and the other types frequently!
Looking for more on Power Automate?
Explore more insights and expertise at smartbridge.com/automation
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!
Other ways to
follow us:
