Learn how to build browser automation flows in Power Automate Desktop that open websites, fill in forms, and extract structured data — without writing code. This hands-on lesson walks through a realistic supplier portal scenario, covering element picking, table extraction, pagination, and timing management.
Imagine you're responsible for tracking competitor pricing every Monday morning. You open five browser tabs, navigate to each product page, copy the prices into a spreadsheet, and repeat this process for thirty products. It takes two hours. Now imagine that same task running automatically while you drink your coffee — no tab-switching, no copy-pasting, no risk of grabbing the wrong number. That's exactly what web automation in Power Automate Desktop can do for you.
Web automation (sometimes called browser automation or RPA — Robotic Process Automation) teaches your computer to operate a browser the same way a human would: clicking buttons, filling in forms, reading text off pages, and navigating between URLs. The difference is that the computer never gets bored, never misreads a number, and can do it in seconds rather than minutes. Power Automate Desktop gives you a rich library of browser actions that make this possible without writing a single line of code — though understanding what's happening under the hood will help you build flows that are reliable rather than fragile.
By the end of this lesson, you'll be able to build desktop flows that open browsers, navigate to URLs, fill in web forms, extract structured data from web pages, and save that data somewhere useful. We'll work through a realistic scenario — pulling order status information from a supplier portal — so every concept you learn has an immediate, practical anchor.
What you'll learn:
Before diving in, you should be comfortable opening Power Automate Desktop and creating a basic flow. If you haven't done that yet, work through Getting Started with Power Automate Desktop: Installing, Recording, and Running Your First Desktop Flow first. You should also understand how variables work in PAD, because web automation produces data that you'll store in variables and use later. The Variables, Lists, and Data Tables in Power Automate Desktop: A Complete Practitioner's Guide article covers this thoroughly.
You'll need:
Before you write a single action, it's worth understanding the plumbing. Power Automate Desktop doesn't control your browser by capturing screenshots and clicking at pixel coordinates (that's the old, brittle way). Instead, it communicates directly with the browser's internal structure through a browser extension.
When PAD tells the browser "click the button with ID submit-order," the browser extension relays that instruction to the browser's engine, which finds that exact element in the DOM (Document Object Model — the structured tree of all HTML elements on a page) and interacts with it programmatically. This is far more reliable than coordinate-based clicking because it doesn't matter if the button moved three pixels to the left or the window was resized.
To install the extension, open Power Automate Desktop, click the Tools menu at the top, then select Browser extensions. You'll see links for Chrome, Edge, and Firefox. Click the one for your browser, and it will open your browser's extension store. Install the extension, then return to PAD. You'll know it's working when the extension icon appears in your browser's toolbar.
Warning
The browser extension must be enabled in your browser's extension settings. If your flows can't connect to the browser, the most common culprit is the extension being present but toggled off. Check this first before spending time debugging elsewhere.
Every web automation flow starts with one of two actions: Launch new [Browser] or Attach to running [Browser]. These live in the Browser automation section of the Actions panel on the left side of PAD.
Use Launch new Edge (or Chrome/Firefox) when your flow needs to start from a known, clean state. Drag this action into your flow canvas. You'll see a configuration dialog with these key fields:
Browser). Every subsequent browser action needs this variable to know which browser to control.After configuring this action, every browser action you add will have a Browser instance field at the top where you reference that same Browser variable.
Sometimes you want your flow to take over a browser that's already open — perhaps because the user has already logged in, or because another part of your process opened it. Use Attach to running Edge for this. It will find an open browser window and connect to it, storing the connection in a variable just like Launch does.
Tip
For attended automation (where a human runs the bot while sitting at their computer), Attach to running browser is often smoother. The user logs into sites manually, then the bot takes over for the repetitive parts. This elegantly sidesteps login automation, which can be tricky with multi-factor authentication.
Once your browser is open and connected, navigation is simple: the Go to web page action takes a URL and directs the browser there. But most real automation isn't just navigation — it's interacting with the page.
This is the concept that determines whether your automation is fragile or robust. When you add an action like Click link on web page or Populate text field on web page, PAD needs to know which element on the page to interact with. It does this using CSS selectors or XPath expressions — patterns that describe where an element lives in the page's HTML structure.
When you record actions or use the element picker (more on that shortly), PAD generates these selectors automatically. But understanding what they mean helps you fix them when they break.
A CSS selector like input#search-box means: "find an <input> element with the ID search-box." A selector like div.product-card > h2 means: "find an <h2> element that is a direct child of a <div> with the class product-card." The more specific the selector, the more reliably it targets the right element — but also the more likely it is to break if the website redesigns its HTML.
Key insight
When recording or picking elements, prefer elements with stable id attributes over those identified only by their position (like "the third <td> in the second <tr>"). IDs are set by developers and tend to stay consistent; positional selectors break the moment a row is added or removed.
You don't need to write selectors by hand. Here's the workflow:
You can name captured elements descriptively — call it SearchButton rather than Element1 — which makes your flow readable.
The Click link on web page action handles hyperlinks. The Click UI element in web page action is more general — it works on buttons, checkboxes, radio buttons, or any clickable element. Configure it by selecting your browser instance and specifying the UI element you captured.
The Populate text field on web page action types text into an input field. The key configuration choices are:
The Set drop-down list value on web page action handles <select> elements. You can set the value by the visible text ("United States") or by the underlying option value attribute. Always prefer visible text unless you know the option values — it's more readable and easier to maintain.
Reading data off a web page is often more valuable than filling forms. PAD provides two primary extraction approaches: extracting a single value, or extracting an entire structured table.
The Get details of element on web page action reads specific attributes or text from a web element. Common use cases:
<span> that shows a stock pricehref attribute of a link to get its URLIn the action dialog, set Attribute name to Own Text to get the visible text content of an element. You can also use Class, Id, href, or any other HTML attribute.
The result is stored in a variable — say ProductPrice — which you can then write to Excel, send in an email, or use in a condition.
This is where web automation gets genuinely exciting. Many websites display data in HTML tables — think search results, order lists, inventory pages. The Extract data from web page action can read an entire table into a DataTable variable, which is PAD's equivalent of a spreadsheet grid with rows and columns.
Here's the process:
Once you have a DataTable, you can loop through its rows, write it to an Excel file using the actions covered in Automating Excel with Power Automate Desktop: Reading, Writing, and Running Macros, or filter it for specific conditions.
Tip
When extracting tables, PAD captures exactly what the browser renders — including any formatting. If a price appears as "$1,234.56" on screen, that's what you'll get in your DataTable, including the dollar sign and comma. Plan for this by using PAD's text-manipulation actions to clean numeric values before doing any math on them.
Real-world data often spans multiple pages — a supplier portal might show 25 orders per page across 10 pages. PAD's Extract data from web page action has a built-in pagination feature. After setting up your extraction:
PAD will automatically click Next Page, extract each page's data, and append it to the same DataTable. This turns what would be 10 separate manual operations into a single, unified extraction.
Warning
Pagination automation is sensitive to loading time. If PAD clicks "Next page" before the new data finishes loading, it may extract duplicate data or miss rows entirely. We'll address how to handle timing in the next section.
If there's one area where beginners consistently struggle, it's timing. Websites load asynchronously — clicking a button doesn't instantly produce results. JavaScript runs, APIs respond, DOM elements appear and disappear. If PAD moves to the next action before the page is ready, the action fails because the target element doesn't exist yet.
The Wait for web page to load action pauses your flow until the browser reports that the page has finished its initial load. Add this after every navigation action and after every click that triggers a page change. It looks like this in your flow:
Go to web page: 'https://supplier-portal.example.com/orders'
Wait for web page to load (Browser instance: Browser)
Click UI element: SearchButton
Wait for web page to load (Browser instance: Browser)
Extract data from web page → OrdersTable
Page load isn't always enough. Modern web apps (React, Angular, Vue) load the initial shell instantly but populate data through background API calls. The page technically "loads" before your data appears. For this, use the Wait for UI element on web page action, which pauses until a specific element becomes visible or disappears.
For example, if the search results table doesn't appear until data loads, capture the table's header element and add a "Wait until element exists" before your extraction action. This is much more reliable than a fixed time delay.
Note
Avoid using Wait actions with fixed durations (like "wait 5 seconds") unless you have no other choice. Fixed waits make your flow slow on fast networks and brittle on slow ones. Condition-based waits — "wait until element X exists" — adapt automatically.
Let's put all of this together. Imagine you need to check the status of 20 open purchase orders on a supplier portal every morning and write the results to an Excel file.
Your flow will:
Here's the flow structure in plain language:
── Launch new Edge → 'https://supplier-portal.example.com' → Browser
── Wait for web page to load → Browser
── Open Excel workbook → 'C:\Reports\OpenOrders.xlsx' → ExcelInstance
── Read from Excel worksheet → ExcelInstance, all contents → OrdersTable
── For each CurrentRow in OrdersTable:
│ ── Populate text field: SearchBox → CurrentRow['OrderNumber']
│ ── Click UI element: SearchButton
│ ── Wait for UI element: ResultsTable (until visible)
│ ── Get details of element: StatusCell → Own Text → OrderStatus
│ ── Write to Excel: ExcelInstance, CurrentRow['OrderNumber'], OrderStatus
── Close Excel → ExcelInstance
── Close browser → Browser
Notice a few things about this structure. The order numbers come from a real file, not hardcoded values. The wait is element-based, not time-based. And the results go right back into the spreadsheet that sourced the work, keeping everything in one place.
This pattern — read a list, loop through it, process each item, write results — is the backbone of most data-oriented web automation. Once you're comfortable with it, you can handle enormous volumes of work that would take humans hours.
Try building this flow to practice each skill from this lesson:
Scenario: Extract the current EUR/USD exchange rate from a public currency information site.
Steps:
https://www.xe.com/currencyconverter/convert/?Amount=1&From=EUR&To=USD.Own Text, store the result in a variable called EURUSDRate.EURUSDRate on screen.Extend the exercise: Modify the flow to also capture the last updated timestamp, then write both values into a new row in an Excel spreadsheet, with today's date in a third column. This gives you the skeleton of a live rate tracker.
"Element not found" errors This is the most common failure. Causes: the element hasn't loaded yet (add a Wait), the website changed its HTML structure (update your selector), or you're on the wrong page (check your navigation logic). Open the UI Elements panel, find the element, and click "Highlight" — PAD will try to find it in the browser and show you if it succeeds.
The flow interacts with the wrong element
Often caused by overly broad selectors. If your selector targets input[type="text"] and there are five text fields on the page, PAD might grab the wrong one. Use the element editor to make the selector more specific — add an ID, a name attribute, or a more specific parent element.
Form values aren't being accepted Try toggling the Simulate typing option on the Populate text field action. Some forms need keypress events; others don't care. Also try adding a Click UI element on the field first to focus it before populating it — some forms behave differently on focused versus unfocused fields.
Browser extension stops responding Restart both PAD and your browser. If that doesn't work, disable and re-enable the browser extension. Occasionally, browser updates push out a version that temporarily breaks extension compatibility — check the Power Automate Desktop release notes if this happens after a browser update.
Pagination extracts duplicate rows The page isn't fully loaded when PAD clicks Next. Add a Wait for UI element action between clicking Next and extracting — specifically, wait for the first row of the new data to appear, which confirms the table has refreshed.
Key insight
Web automation flows break when websites change. This is unavoidable — websites are updated constantly. Build your flows so that when they break, they fail loudly (with clear error messages or log entries) rather than silently producing wrong data. The Desktop Flows: Automate Legacy Applications with RPA in Power Automate article covers error-handling patterns for PAD flows that apply directly to browser automation.
You've covered the full arc of web automation in Power Automate Desktop: connecting to browsers through the extension, launching and attaching to browser sessions, picking and interacting with web elements, extracting single values and full tables, handling pagination, and managing the timing issues that cause most failures.
The skill that separates reliable web automation from flaky web automation is understanding selectors and wait conditions. Invest time in making your element selections as specific and stable as possible, and always use condition-based waits rather than fixed delays.
From here, consider combining web automation with the other PAD capabilities you've seen in this learning path. Pull data from a portal and write it directly to Excel using the techniques in Automating Excel with Power Automate Desktop: Reading, Writing, and Running Macros. Build conditional logic into your loops so your flow responds differently based on what it finds on the page, using the loop and condition patterns in Working with Conditions, Loops, and Variables in Power Automate. And when your data collection is complete, consider triggering a cloud flow to email stakeholders with the results — a pattern covered in Your First Power Automate Flow: Automated Email Notifications That Actually Work.
Web automation turns repetitive browser work into a solved problem. The two hours of manual price checking you imagined at the start of this lesson? It runs in four minutes now, on a schedule, while you do something that actually requires your judgment.