Power Automate Desktop connects portals without an API via the browser: actions, the Recorder, and the limits of web automation.
Many portals that departments work with every day, supplier portals, government portals, booking systems from individual software vendors, simply don't offer an open interface. Without an API, the only option is usually manual clicking, filling in forms, and retyping data between two systems, often several times a day and always following the same pattern. Power Automate Desktop closes exactly this gap with web automation: a digital worker operates the browser just as you would yourself, reads out data, fills in forms, and clicks buttons, all without the target system needing to provide an API for it.
This article shows how web automation in Power Automate Desktop (PAD) works technically, which actions are available for forms, clicks, and data extraction, how the Recorder helps with this, and where the limits of this approach lie. You retain control over which browser the flow uses and how robust the automation is against changes to the portal.
According to the official documentation, browser automation is a special case of user interface automation designed specifically for interacting with web elements, as stated in the article Automate webpages. Instead of working against a REST or SOAP interface, PAD reads the page's HTML structure directly and emulates clicks, entries, and selection lists via the Document Object Model. For you, this means: any portal that can be operated in a browser can in principle be automated, regardless of whether the provider ever intended an API for it. Four standard browsers are supported, Microsoft Edge, Internet Explorer, Google Chrome, and Mozilla Firefox, in addition to the built-in automation browser, which is ready to use immediately without any additional installation.
Before web automation can run, you need a browser instance. For this, the actions Launch new Microsoft Edge, Launch new Chrome, and Launch new Firefox are available, each with the option to open a new instance or attach to one that's already running. For Edge, Chrome, and Firefox you first need to install the matching extension and enable it in the browser, otherwise the automation fails with an error message. You'll find the necessary links and steps in Install Power Automate browser extensions.
For some time now, WebDriver has also been available as an alternative interaction method to the browser extension, selectable via the Browser interaction method field in the Launch action. To use it, place the WebDriver executable files under %LocalAppData%\Microsoft\Power Automate Desktop\WebDrivers, matching the installed browser version. Important to know: WebDriver can only attach to browser instances that the flow itself started, not to manually opened windows, and it doesn't work if an organizational policy forces the browser into a mandatory login. WebDriver also isn't available at all for Internet Explorer. In most projects, the classic browser extension therefore remains the more robust default choice.
For the actual interaction with the page, PAD provides a whole group of actions. The most important ones in practice:
By default, these actions don't move the mouse pointer visibly across the screen but instead trigger the interaction via a JavaScript event. This has a practical advantage: the flow still runs reliably even when the browser is minimized or the target tab isn't currently the active one in the foreground, so you can keep working on your computer in the meantime. If a portal doesn't respond to these emulated events as expected, physical interaction can additionally be enabled for individual actions such as Click link on webpage or Populate text field on webpage. In that case, PAD actually moves the mouse pointer, but the browser then needs to be in the foreground with the target tab focused.
Besides filling in forms, reading out data is the second major use case. For individual values or element properties, you use the Get details of element on webpage action; for larger structured amounts of data, the Extract data from webpage action. This action supports five extraction modes, single value, hand-picked values, list, table, and entire HTML table, and can be operated entirely via the Live Web Helper: you mark the desired elements by clicking, and PAD automatically detects when it's a list or table, as soon as at least two comparable elements have been selected. For special cases, CSS selectors can also be written or adjusted manually, including an optional regular expression for fine selection. If the data is spread across multiple pages with the same layout, you additionally define a pager element so that extraction automatically pages forward until all pages, or a specified number of pages, have been processed.
If you don't want to click together every single action, you can instead start the Recorder via the button in the flow designer's toolbar. After clicking Record, PAD tracks mouse and keyboard activity and automatically generates both UI and browser automation actions from it, as described in Record desktop flows. You can start a browser in three ways: via the three-dot menu in the Recorder window and the Launch new web browser option, by recording in an already open browser, or by manually opening it via a desktop shortcut. For drop-down lists, date pickers, and color pickers, the Recorder displays its own helper dialogs where you enter the desired values directly instead of selecting them live in the portal. Important for practice: the Recorder delivers a basic framework, not a finished end product. It generally doesn't record conditions and loops; you should afterward review the generated steps in the flow designer, clean them up, and add error handling.
Web automation is powerful, but not limitless. A few points you'll encounter in practice:
Exactly where web automation is worthwhile for your portal, and where a more stable alternative such as a hidden API or a data export makes more sense, is best assessed on the basis of the specific case, for example as part of a Power Automate consulting.
No, you install the extension once per browser and computer, not per portal. After that, PAD can automate any webpage in that browser, as long as the extension stays enabled and no company policy blocks it.
The affected UI element definition in the flow then no longer finds the expected element, and the action fails with an error such as "Element with specified CSS selector not found." In this case, simply recapture the element in the Live Web Helper and replace the old definition.
Not fundamentally. WebDriver offers additional capabilities but has documented limitations with parallel executions, with attaching to manually opened windows, and with mandatory organizational logins. For most standard scenarios, the browser extension remains the simpler and more stable choice.
Yes, via the Click download link on webpage action, or by clicking a download link and having PAD process the storage location through downstream file system actions. If a Windows-native Save As dialog appears in the process, you additionally need UI automation actions for it, since this dialog isn't part of the webpage.
Yes, that's actually the usual path. Web automation bridges the time without an interface, often for years. As soon as an API becomes available, the affected flow section can be swapped out without affecting the rest of the process logic.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
How to connect a legacy ERP without an API using RPA: MSAA selectors, attended/unattended modes, and the limits of Power Automate in SMEs.
The Recorder in Power Automate Desktop captures clicks as flow actions. What it can do, how UIA and MSAA work, and where it hits its limits.
Excel automation with Power Automate Desktop: actions for reading, writing, sorting, and filtering locally without a cloud connector.
When a portal offers no API, browser-based web automation is often the only option left, but form logic, selectors and error cases make the build more demanding than expected. NordFlux develops robust RPA solutions for exactly these portal and legacy system cases, and also takes over ongoing operation. In the first conversation we look at your portal and show where the pitfalls lie.
