Web automation: connecting portals without an API

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.

Why web automation closes the gap without an API

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.

Launching the browser: extension or WebDriver

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.

Filling in forms and clicking buttons

For the actual interaction with the page, PAD provides a whole group of actions. The most important ones in practice:

• Populate text field on webpage enters values into input fields.
• Set drop-down list value on webpage selects an entry from a selection list.
• Press button on webpage and Click link on webpage trigger clicks, including options for whether to wait for the new page to load after the click and how to handle any popup dialog that may appear.

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.

Extracting data from webpages

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.

Recording web flows without code using the Recorder

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.

Limits and typical pitfalls

Web automation is powerful, but not limitless. A few points you'll encounter in practice:

• Operating-system-native dialogs such as Save As, Open, or file upload are not part of the HTML page and cannot be controlled with the web automation actions; for these you additionally need UI automation actions for the Windows dialog itself.
• If a flow runs in parallel with multiple browser instances via WebDriver, this can lead to unreliable behavior, because physical browser interactions require a focused window.
• If the portal operator changes the page structure, the corresponding UI element definition in the flow must be adjusted; web automation is therefore more maintenance-intensive than a genuine API connection and should be checked regularly.
• The built-in automation browser works without any additional configuration, but supports neither tabs nor opening links in new windows.

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.

Frequently asked questions

Do I need a separate browser extension for every portal?

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.

What happens if the portal's layout changes?

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.

Is WebDriver better than the classic browser extension?

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.

Can I also download files from a portal with web automation?

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.

Is web automation worthwhile if an API becomes available later?

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.