Nov 13, 2019
This is our second episode recorded at the Microsoft Ignite podcast center. Today's guest is Stephen Siciliano, Principal Group PM for Power Automate. MVP Jerry Weinstock also joins us to discuss his white paper "A guide to building enterprise-ready flows."
During Ignite 2019, Microsoft announced the rebranding of Microsoft Flow as Power Automate. During this episode, we delve into the rebranding of the platform and some best practices for Power Automate flows.
Reminder: Microsoft is giving away Surface earbuds to one lucky listener–register at https://aka.ms/PodcastSweepstakes for your chance to win.
This episode is brought to you by Maplytics by Inogic.
What is Power Automate?
Power Automate in one sense is a new name for what we know and love as Microsoft Flow. We decided that now was the perfect time to make it part of the Power family, along with Power Apps, Power BI, and Power Virtual Agent.
What was the thought process behind the name change?
Another factor driving the change was the introduction of Robotic Process Automation. With RPA you can now build automation that uses the user interface of applications to be able to automate them. So you can write data to them, read data from them, and simulate mouse clicks. There are a bunch of applications out there that don’t have any api—even with custom connectors, you have to have some kind of rest api to be able to work with something. Our goal with the new UI flow capability is to open the door to anything that you can do on your PC you can now automate with power automate.
The way that RPA works is you have to directly interact with the UI. There are two types of RPA, one is attended RPA. That means somebody is actually sitting at the computer and has the UI in front of them and presses a button and it pulls the data from the application, the other type of RPA is called on attended RPA, which runs somewhere else without a human interacting with it. The best place to run that is in an Azure VM. For on attended RPA, you need to make sure that the automation does not depend on any type of human interaction, including things like login, getting credentials, handling error handling, for example you might have a dialog box pop up. The benefit of unattended RPA is you can scale it and have multiple operations happening in parallel.
How do you manage performance with RPA?
When you record a UI Flow, you record everything, including delays waiting for things to pop up and for jobs to complete, and you can adjust the amount of time that it takes. Say you have it save a file, and sometimes it takes twice as long, we have built-in retries, so if the dialog hasn’t appeared yet we will keep retrying to look for that control for some period of time until it pops up. You need to make sure that as you are building your flows you are testing them across a variety of file sizes and data types to make sure that it works, so that when it takes longer the retry policy will catch it, otherwise you may find yourself in a situation where your process times out and fails.
Will there be an RPA custom connector?
Today we support two types of technology: for Windows applications, we use the UI automation framework that is included in modern versions of Windows and is the same framework that all of the accessibility features in Windows use. As long as the application supports the UI automation APIs, we can automate it.
For web applications, we use a framework called Selenium, which is a very common web automation framework. As long as your web app is scriptable via Selenium, that works as well.
There are some applications that don’t work with the Windows UI automation framework and are not web-based. For those applications today we don’t do a very good job of handling automation for them. For example, if you hover over Java-based application, you will get a warning that we don’t support this application yet. Over the next few months we are going to add a few more application types that we can support, and someday even having a custom connector equivalent where we can have our own custom application type is something we’ve thought about, but we think that the UI automation framework and Selenium will cover the majority of applications, and what we are looking at doing is leverage Computer Vision to provide automation, even if there is no API at all.
How will this help on-premises customers?
The Power Automate service runs in the cloud, but with the on-premise data gateway, which we have had for almost five years, you can connect to anything running on-premise, and the UI flow itself executes locally on the machine. So theoretically, if you have a long-running process, you could unplug the ethernet cable while the process is running and if you plug it in again before the process finishes, it will just work. We don’t support offline yet where I could queue things up and send them down to the machine and replay them later, but that’s another thing that we are looking at in the future.
Do we still say we are building “flows?”
Absolutely—“flow” is like the parent class, the base for everything. The core thing is a flow. There are different types of flows:
You use Power Automate to create flows.
What does this mean for Logic Apps? Any plans to bring RPA functionality to Logic Apps?
Not exactly—even before these announcements we had functionality in Flow that was not in Logic Apps. Business Process Flow and building on CDS solutions are some examples. We are going to continue to invest in types of flows that are not the automated flows, which are the Logic Apps equivalents. As we continue to invest in Business Process Flow and UI Flow, these are additional types of abstractions that continue to build on top of that layer, and these won’t necessarily be brought back into the Logic Apps code base.
Other topics discussed in this episode: