Learn how to build a desktop flow that opens a Windows application, populates form fields from a data source, and submits records automatically. This lesson covers every step from launching the app to handling post-submission state — with a hands-on exercise you can run in minutes.
Picture this: every morning, your team spends the first 90 minutes of their day copying rows from a spreadsheet into an aging inventory management system. The work is manual, repetitive, and error-prone — and everyone doing it knows it. This is exactly the kind of task that Robotic Process Automation (RPA) was invented to solve, and Power Automate Desktop is Microsoft's tool for doing it without writing a single line of traditional code.
In this lesson, you're going to learn how to build a desktop flow that opens a Windows application, navigates its interface, populates form fields with real data, and submits that form — automatically, reliably, and repeatedly. Whether you're dealing with a modern WPF application, a VB6-era data entry tool, or something in between, the same core techniques apply.
By the end of this lesson, you'll be able to take a repetitive desktop data entry task and hand it off to a bot permanently.
What you'll learn:
You should be comfortable opening Power Automate Desktop and understand the basic concept of what a desktop flow is. If you haven't yet installed the tool or run your first flow, start with the guide on getting started with Power Automate Desktop before continuing here.
You should also have a basic sense of what variables are. If that's fuzzy, skim Variables, Lists, and Data Tables in Power Automate Desktop first — you'll need them heavily in this lesson.
Before we write any actions, let's build a mental model of what Power Automate Desktop is actually doing when it interacts with a Windows application.
Every visible element in a Windows application — a text box, a button, a dropdown list — is a real object with properties. Windows exposes these through a technology called UI Automation (sometimes called UIA), which gives automation tools a structured way to read and write to those elements without simulating raw mouse movements. When Power Automate Desktop interacts with a text box, it's not just clicking a pixel on the screen; it's reaching into the application's element tree and directly setting or reading the value of that control.
This is why RPA built on UI Automation is dramatically more reliable than older coordinate-based approaches (clicking at X=540, Y=320 and hoping the button is still there). If the window moves or resizes, a proper UI Automation selector still works because it's targeting the element by its properties — its name, class, role, and position in the application hierarchy — not by screen coordinates.
Key insight
The difference between fragile automation and reliable automation often comes down to this: are you targeting elements by their identity, or by their position? UI Automation targets identity. That's why it holds up across screen resolutions, theme changes, and window repositioning.
When we build a flow in this lesson, every click and keystroke will be anchored to a named UI element. We'll capture those elements with Power Automate Desktop's built-in recorder or element picker, and the flow will use their selectors to find them at runtime.
The first thing any data entry flow needs to do is open the application. Power Automate Desktop provides the "Run application" action for exactly this.
In the flow designer, click the search bar in the Actions panel on the left side. Type "Run application." Drag it into your flow canvas or double-click it to add it.
You'll see a dialog with these key fields:
C:\Program Files\Inventory\InventoryApp.exe. You can also use environment variables like %ProgramFiles%\Inventory\InventoryApp.exe.After the action runs, Power Automate Desktop will store a reference to the application window. This isn't a variable you'll use directly, but it helps the engine know which window's elements belong to which application — important if multiple windows are open.
Tip
If your application is already open when the flow starts (common in attended automation where a user triggers the bot mid-session), you don't need to launch it again. Use the "Get window" or "Focus window" actions to bring it to the foreground instead. Check out the Power Automate Desktop Action Library guide for a full breakdown of window management actions.
Before you can populate any fields, you need to tell Power Automate Desktop which fields you mean. This is done through UI element capture, which is the process of pointing the tool at an element in your application so it records a selector — a structured description of that element that can be used to find it again at runtime.
Here's how to capture an element:
The captured element now has a selector — a query like Window[Title = "Inventory Manager"] > TextInput[Name = "PartNumber"] that describes exactly how to find that field. You can view and edit this selector by right-clicking the element in the UI Elements panel.
Warning
Capturing elements while the application is in its "normal" state is critical. If you capture a text box while a modal dialog is open, the selector may include the dialog as part of the path, causing failures when the dialog isn't present. Always capture elements from the application's standard, unobstructed state.
Understanding selectors deeply will save you hours of debugging. The full treatment of this topic is in UI Elements and Selectors in Power Automate Desktop — it's essential reading before you automate anything complex.
Now we get to the core of the lesson. A typical data entry form might have:
Each type of control has its own action in Power Automate Desktop.
Use the "Populate text field in window" action. After selecting your captured UI element, set the Text field to the value you want to enter. This can be a literal string like "AX-1042", or — much more usefully — a variable like %CurrentRow['PartNumber']%.
The action has a mode setting: Replace text (clears the field first, then types) vs. Append text (adds to whatever is already there). For data entry, you almost always want Replace text to avoid duplicating previous entries.
Under the hood, "Populate text field" uses UIA's SetValue method — it directly sets the element's value rather than simulating keystrokes. This is faster and more reliable than keyboard simulation for most fields.
Tip
Some older or non-standard applications don't respond correctly to SetValue. If a field appears populated visually but the application doesn't "see" the value when you submit, try switching the action's Simulate typing option to True. This sends keystrokes instead of setting the value directly, which triggers the application's change-detection events properly.
Use the "Select option in drop-down list in window" action. You can specify the option either by its visible text (e.g., "Electronics") or by its index (0 for the first item, 1 for the second, etc.). Text-based selection is safer because indexes change if someone adds options to the list.
If the dropdown is a combo box (a text field that also allows typing), you may need to use "Populate text field in window" instead, followed by a UI interaction to close the suggestion dropdown.
Use the "Set checkbox state in window" action. You provide the UI element and set the desired state to Checked or Unchecked. The action is idempotent — running it twice with the same state doesn't cause problems, which makes it safe to use without checking current state first.
Use the "Click UI element in window" action. Capture the button element, and Power Automate Desktop will click it at runtime. For critical buttons like Submit or Save, always add a wait action afterward to let the application process the submission before the flow moves to the next record.
Individual field population is just table stakes. The real power comes from driving those actions with a data source — reading each row from a spreadsheet, processing it through the form, submitting, and moving to the next row automatically.
Here's a realistic scenario: you have an Excel file with 50 new supplier invoices. Each row has columns: SupplierID, InvoiceNumber, Amount, Category, and DueDate. Your job is to enter each one into a legacy accounts payable application.
The high-level flow structure looks like this:
Launch Excel → Read invoice data into DataTable
Launch AP application
For Each Row in DataTable:
Populate SupplierID field with Row['SupplierID']
Populate InvoiceNumber field with Row['InvoiceNumber']
Populate Amount field with Row['Amount']
Select Category from dropdown using Row['Category']
Populate DueDate field with Row['DueDate']
Click Submit button
Wait for confirmation (element appears or timeout)
[Optionally: log result back to Excel]
End Loop
To implement this, you'll use the "For each" loop action in Power Automate Desktop. Set the value to iterate over as your DataTable variable. Each iteration gives you a CurrentItem variable that represents one row — you access individual cells as %CurrentItem['ColumnName']%.
Reading the Excel data is straightforward with the "Read from Excel worksheet" action — the full mechanics of that are covered in Automating Excel with Power Automate Desktop.
Key insight
Notice that the application launch and the loop are separate. You launch the application once, then process all 50 rows. Don't relaunch the app on every iteration — that's slow and usually unnecessary. Treat the launch as setup, and the loop as the work.
Clicking Submit is not the end of the story. After submission, your application will do something: it might clear the form, show a confirmation message, navigate to a different screen, or display an error. Your flow needs to handle whichever of these actually happens.
Waiting for a known element: The most robust technique is to wait for a specific UI element that signals successful submission. For example, if your application shows a "Record Saved" label after a successful save, use the "Wait for UI element to appear" or "Wait for UI element to disappear" action. Set a reasonable timeout (15–30 seconds for most apps). If the element doesn't appear within the timeout, an exception is raised and you can handle it.
Adding a static wait: For simpler cases, the "Wait" action (which just pauses for a fixed number of seconds) can work, but it's brittle — if the app is slow one day, a 2-second wait might not be enough. Reserve static waits for situations where there's no predictable element to wait for.
Handling confirmation dialogs: Some applications pop up a "Are you sure?" dialog after submission. You'll need to capture the dialog's button and click it as part of your flow. If these dialogs are system-level Windows dialogs rather than application dialogs, the approach is slightly different — the dedicated lesson on Automating Windows System Dialogs and Pop-Up Handling covers this in detail.
Data entry automation without error handling is a liability. What happens when row 23 has a malformed date value? Or the application hangs on record 47? Without error handling, your flow crashes and leaves 27 records unprocessed — and you may not even know where it stopped.
The right pattern is to wrap your per-record actions in a "On block error" block. Inside the error block, you can:
Warning
Don't just swallow errors silently. A flow that logs "processed 50 records" when it actually skipped 15 due to errors is worse than a flow that fails loudly, because it gives you false confidence. Always surface failures visibly in your output.
The full error handling mechanics — including retry policies and how On block error blocks nest — are explained in Error Handling in Desktop Flows.
For forms with many fields, capturing elements one by one is tedious. Power Automate Desktop's Desktop Recorder can watch you perform the data entry manually and generate a draft flow from your actions automatically.
To use it: in the flow designer, click the Record button in the toolbar. A small recorder control appears. Navigate to your application and perform the data entry steps as you normally would — click the field, type a value, select from the dropdown, click Submit. When you're done, click Done in the recorder. Power Automate Desktop generates a sequence of actions corresponding to what you did.
The generated flow will have hardcoded values (whatever you actually typed during recording). Your next job is to replace those literal strings with variable references — %CurrentItem['PartNumber']% instead of "AX-1042". The structure and element captures are already done; you're just parameterizing them.
Tip
The recorder is a starting point, not a final product. It often generates redundant click actions (like clicking a field before populating it, which "Populate text field" doesn't need). Clean up the generated flow by removing unnecessary steps and replacing hardcoded values with variables before testing.
The complete guide to recording techniques is at Capturing and Replaying Mouse Clicks and Keystrokes with the Power Automate Desktop Recorder.
Let's put this all together. For this exercise, you'll need:
Step 1 — Create your data. In Power Automate Desktop, add a "Create new list" action and name it %EntryList%. Then add three "Add item to list" actions to insert the strings: Invoice-001, Invoice-002, and Invoice-003.
Step 2 — Launch Notepad. Add a "Run application" action. Set the application path to notepad.exe (Windows can find it by name alone without a full path). Set "After application launch" to "Wait for the application to load."
Step 3 — Build the loop. Add a "For each" loop. Set the iteration variable to %CurrentItem% and the list to %EntryList%.
Step 4 — Capture the Notepad text area. Inside the loop, add a "Populate text field in window" action. Use the element picker to capture Notepad's text area (the large white editing area). Set the text to %CurrentItem% and make sure "Replace text" is selected.
Step 5 — Add a pause. After populating the field, add a "Wait" action set to 1 second so you can watch it work.
Step 6 — Run the flow. Click Run. You should see Notepad open, the text area get populated with Invoice-001, then replaced with Invoice-002, then Invoice-003.
This is the skeleton of every data entry automation you'll ever build. The real-world version just has more fields, a real data source (Excel or a database), and a Submit button instead of a Wait.
Problem: The flow runs but nothing appears in the text box. This usually means the application isn't receiving the input. First, try enabling Simulate typing on the Populate action. Second, make sure the application window is in focus — add a "Focus window" action before the populate step.
Problem: The selector fails with "Element not found." The element exists, but the selector can't locate it. This usually means something about the application's state changed — a dialog is open that the recorder didn't account for, or the window title changed. Open the UI Elements panel, right-click the element, and click "Highlight" to test whether it can be found right now. If not, recapture the element, or adjust the selector in the element editor. The UI Elements and Selectors lesson walks through selector troubleshooting in depth.
Problem: The dropdown selection fails silently — the field stays on the default value. Try selecting by index instead of text, or check whether the visible text in the list exactly matches your variable value (including capitalization and whitespace). A trailing space in your data can cause a mismatch.
Problem: The flow processes the first record correctly, then fails on the second. This is almost always a post-submission state issue. The form didn't fully reset or navigate back before you tried to populate it again. Add a "Wait for UI element to appear" action waiting for a field that signals the form is ready (like the first text box returning to an empty state, or a "New Record" label appearing).
Problem: The application crashes or becomes unresponsive mid-run. Add an "On block error" wrapper around your loop body. Inside it, use "Close window" on the application, then re-launch it using your original "Run application" action. This makes your bot self-healing for application-level crashes.
You now have a complete foundation for automating Windows desktop application data entry with Power Automate Desktop. Here's what you've covered:
From here, natural next steps depending on your use case:
The pattern you learned today — launch, loop, populate, submit, handle — is the backbone of RPA. Master it here, and every other automation scenario becomes a variation on a theme you already understand.