Browser automation

What it does

A dedicated group of actions for driving webpages — launching or attaching to a browser, filling forms, clicking links, and pulling structured data out of pages. It's a specialised form of UI automation that talks to the DOM through a browser extension rather than poking at pixels.

Key facts

Supported browsers are Microsoft Edge, Google Chrome, Mozilla Firefox and Internet Explorer, plus the built-in Automation browser that works with no setup at all.
Edge, Chrome and Firefox need the Power Automate extension. From version 2.27 the extension files ship with the installer under C:\Program Files (x86)\Power Automate Desktop\BrowserExtensions, so you can side-load them where store access is blocked.
WebDriver is the alternative to extensions. Drop the matching x64 driver into %LocalAppData%\Microsoft\Power Automate Desktop\WebDrivers, unrenamed and not nested in subfolders, and match the driver version to the browser.
You must launch or attach to a browser instance before any other browser action will work. Every browser action after that needs a web UI element — desktop elements aren't offered.
Most browser actions drive the page through JavaScript rather than moving the mouse, so they run with the browser minimised or the tab unfocused. Turning on physical interaction on actions like Click link on web page removes that freedom: the browser must be visible and the tab focused.
Extract data from web page with the live web helper handles lists, tables and whole HTML tables, supports pagers for multi-page extraction, and lets you hand-edit CSS selectors.
The recorder detects an already-open browser and generates the launch action for you, and distinguishes the browser chrome (desktop elements) from the page (web elements) automatically.
Browser instances can't be attached to across Windows users — Power Automate won't attach to a browser launched by a different system account.

When to use / skip

Browser automation beats desktop UI automation for anything inside a page, every time. It's faster, it survives resolution changes, and it doesn't need the window in front. Skip it entirely if the site has an API — Invoke web service or a proper connector will be quicker to build and vastly cheaper to maintain than a screen-scrape. And skip the Automation browser for anything modern; it's Internet Explorer underneath, with no tab support.

Configuration decisions

Extension versus WebDriver, which usually comes down to whether the client's endpoint management will allow store extensions.
Which browser is the standard for automation, and whether it's version-pinned — extension and driver compatibility both track the browser.
Whether physical interaction is enabled on specific actions, accepting that those flows can no longer run in the background.
How extensions get deployed to unattended machines, since nobody is there to click through a store install.
Whether page data comes out via extraction actions or a direct HTTP call.

Gotchas

"Continue running background apps when the browser is closed" left on in Edge or Chrome leaves orphaned processes that confuse the next run. Turn it off as part of machine build.
The extension has to be installed in the profile the unattended session actually uses. Installing it once as the maker doesn't help the service account.
WebDriver versions drift out of step every time the browser auto-updates, and the failure is a hard launch error rather than anything descriptive.
There's no headless mode in these actions. Browser automation runs without a visible window in the sense that it doesn't need focus, but it still needs a real Windows session with a desktop — which is exactly what unattended runs provide.
Firefox modal alerts can freeze the browser and stall a flow; the documented fix is setting prompts.tab_modal.enabled to false in about:config.

Consultant notes

Get the browser extension into the standard machine image or the Intune/GPO deployment. Doing it by hand per machine doesn't scale and gets forgotten on the new box.
If the client is still automating Internet Explorer or the Automation browser, treat it as technical debt with a deadline, not a working solution.
Data extraction with a pager is the single highest-value pattern here — it replaces a lot of manual copy-paste and it's quick to demo.
Warn the client that browser auto-update is now the main source of unplanned RPA outages. Ask whether they can pin versions on automation machines.

Recheck after browser or extension version changes, or if the client moves to a managed-extension policy