"JavaScript Functions" or "Web Automation" in Microsoft Power Automate Desktop (PAD)

When building software robots with Power Automate Desktop (PAD) you have a whole set of building blocks to choose from. These are called Actions in PAD and enable people from a non-technical background and/or people with little to no prior knowledge about HTML and JavaScript to automate things on the web.

The low-code way of doing things often involves the robot navigating via the user interface (the UI elements). What every RPA-developer will tell you is that this makes for an unstable robot. This is because UI elements will change ever so often, creating problems for your robot. Changing the layout of a page may result in you spending a lot of time figuring out why the robot is no longer able to click an element or fill in a webform the way that it used to.

Making Your Robots Stable with JavaScript

Rather than navigating to a button using UI element actions in Microsoft Power Automate Desktop (PAD), you can simply run the JavaScript function.

document.querySelector('[/*CSS SELECTOR HERE*/]').click()

Similarly, if you want to input a text into a form you can run another JavaScript function:

function ExecuteScript() { 
document.getElementById(/*ElementID Here*/).value = "Some Text I Want To Insert";
}

Of course, you still risk that the owner of the website you a navigating decides to change the element ID or CSS selectors. But if this is the case chances are that the UI automation would fail as well.

In any case, I believe that using JavaScript functions make for more stable robots in general (even better would be to use APIs if possible).

What are the Downsides of Using JavaScript Functions with Power Automate Desktop?

Well, for starters, this is not the way that Power Automate Desktop (PAD) or many other low-code RPA platforms are intended to be used. They are very much aimed at so-called Citizen Developers, which is people with limited coding skills. The main reason for using a low-code RPA platform is that companies can get people to create stuff that it would normally take an expensive programmer to do.

Building software robots with low-code tools but making your robots with real code instead of the build-in drag-and-drop features makes it difficult for a person from a non-programming background to develop and maintain the robots (especially if you are using APIs). It is in other words a trade-off between user-friendliness for the non-technical RPA-developer and stability of the robotic process automation.