Learn how to use Power Automate Desktop's built-in action library to launch applications, manage windows, and manipulate files with confidence. This lesson takes you from the basics of the action library structure to building a complete, realistic file-processing automation from scratch.
Imagine you're a data analyst who receives a batch of CSV exports from three different systems every morning. Your job is to open each file, check that it isn't empty, copy it to an archive folder, then launch a legacy desktop application, paste the data in, and close everything down cleanly. Done manually, that's twenty minutes of clicking and context-switching before you've even had coffee. Done with Power Automate Desktop, it's a flow that runs while you're doing something more useful.
The secret to making that automation work isn't a complex script — it's knowing which built-in actions to reach for and how to wire them together properly. Power Automate Desktop ships with a massive action library covering everything from simple file copies to full window management and application launching. The challenge for beginners isn't finding actions; it's understanding what each one actually does under the hood, when to use one variant over another, and how to avoid the subtle bugs that trip up newcomers.
By the end of this lesson, you'll be able to build a complete automation that opens an application, manages its window state, reads and manipulates files, and shuts everything down in a controlled way. You'll understand not just the how but the why behind each action choice.
What you'll learn:
This lesson assumes you have Power Automate Desktop installed and can open the flow designer. If you haven't done that yet, start with Getting Started with Power Automate Desktop: Installing, Recording, and Running Your First Desktop Flow before continuing here. You should also have a basic comfort with the concept of variables — if not, Variables, Lists, and Data Tables in Power Automate Desktop: A Complete Practitioner's Guide will give you the foundation you need.
When you open the Power Automate Desktop flow designer, the left panel is the Action Library — your entire toolkit. Actions are organized into groups that map roughly to the type of thing you're controlling: System, File, Folder, Clipboard, Windows, Process, and many more.
Think of the action library like a well-organized hardware store. You wouldn't look for a screwdriver in the electrical aisle. Similarly, actions that move files live under "File," actions that control running windows live under "Window," and actions that launch executables live under "System" (specifically, the "Run application" action) or "Process."
To find an action, you can either expand the category tree manually or type into the search box at the top of the panel. Searching is almost always faster once you know roughly what the action is called. Type "copy file" and the relevant action surfaces immediately.
When you drag an action into your flow canvas (or double-click it), a configuration dialog opens. Every field in that dialog is either a literal value you type in, a variable you reference using %VariableName% syntax, or an expression. Almost every action also produces one or more output variables — a file path, a status code, a window handle — that you'll use in subsequent steps.
Tip
Get in the habit of renaming output variables immediately after adding an action. PAD defaults to generic names like %AppProcessId% or %CopiedFile%. Renaming them to something like %NotePadProcessId% or %ArchivedReportPath% makes your flow dramatically easier to read and debug a week later.
The first thing most automations need to do is open something. The "Run Application" action — found under System — does exactly what it says: it launches an executable, just like double-clicking a file in Explorer.
Here's what the key fields mean:
.exe file, such as C:\Program Files\MyApp\myapp.exe. You can also pass command-line arguments in the Command line arguments field.Warning
"Wait for application to load" sounds reliable, but it only waits until the process starts — not until the UI is fully rendered and interactive. For apps that have slow splash screens or database connections on startup, you'll need to follow this action with a "Wait for window" action (covered shortly) to be truly safe.
The action produces an output variable for the process ID, which you can use later to close or focus the application precisely. Store it — you'll need it.
A realistic example: launching Notepad to process a text file.
Run application
Application path: C:\Windows\System32\notepad.exe
Command line arguments: C:\Reports\DailyExport.txt
Window style: Normal
After application launch: Wait for application to load
→ Saves process ID to: %NotepadProcessId%
Once an application is running, you often need to control its window before you can interact with it reliably. The Window action group is where this happens.
"Focus window" brings a specific window to the foreground and makes it the active application. You identify the window by its title, which supports wildcards. For example, if your application window title is "Sales Report - Q4 2024.xlsx - Excel," you can match it with *Sales Report* rather than hard-coding the full title.
This wildcard matching is important. Window titles in real applications often include the file name or the current document, so a rigid exact-match approach breaks the moment a different file is open.
The "Get window" action captures the current state of a window: its position (X, Y coordinates), its dimensions (width and height), and whether it's minimized, maximized, or normal. This is useful when you need to confirm a window is actually visible before trying to click things inside it, or when you need to position two windows side by side for a comparison.
"Set window state" lets you programmatically maximize, minimize, restore, or move a window. You can also set precise pixel dimensions with "Set window size." In practice, maximizing a window before interacting with it is a reliable pattern — a maximized window has predictable element positions, which makes UI automation less fragile.
Set window state
Window title: *Notepad*
Window state: Maximized
This is one of the most valuable actions in the entire library: "Wait for window." It pauses your flow until a window with a matching title appears (or disappears). Without it, you'd be forced to add arbitrary "Wait" delays — the automation equivalent of hoping traffic is light today.
Wait for window
Window title: *DailyExport*
Window state: Open
Timeout: 30 seconds
If the window doesn't appear within the timeout period, the action raises an error — which is exactly what you want. It means your flow fails loudly rather than silently proceeding and corrupting data. Combine this with Error Handling in Desktop Flows: On Block Error, Retry Policies, and Recovery Screenshots to handle those timeout failures gracefully.
Key insight
The "Wait for window" action is always preferable to the generic "Wait" (sleep) action. A fixed wait of 5 seconds might be too short on a slow machine and wasteful on a fast one. "Wait for window" is adaptive — it proceeds the moment the condition is met and only times out if something is genuinely wrong.
"Close window" lets you close any window matching a title pattern. Alternatively, if you have the process ID from "Run application," you can use "Terminate process" under the Process group to force-close the entire application. Use "Close window" when you want the application to close gracefully (prompting to save, etc.), and "Terminate process" when you need to kill it unconditionally.
File manipulation is the bread and butter of desktop automation. The File action group covers the most common operations you'll need.
Before you try to copy, open, or process a file, confirm it's actually there. "If file exists" is a condition action — it evaluates to true or false and lets you branch your flow accordingly.
If file exists
File path: C:\Exports\DailyReport_%CurrentDate%.csv
Then: [proceed with processing]
Else: [log an error or send an alert]
This pattern — check existence before acting — prevents the embarrassing scenario where your flow crashes on a Tuesday because the upstream system didn't generate today's file.
"Copy file" moves a copy of a file to a destination folder or path. Key settings:
The action outputs %CopiedFile%, which is the full path of the copied file. This is useful when you want to pass the archived file path into the next step.
"Move file" is logically identical to copy, except the source file is removed after the transfer. "Rename file" changes just the filename while keeping it in the same directory.
A common pattern in data pipelines is to rename a file after processing it — for example, appending _processed to the filename — so you can tell at a glance which files have been handled. That's cleaner than using a separate "processed" folder when you're dealing with a small daily batch.
Rename file
File to rename: C:\Exports\DailyReport_2024-11-15.csv
New file name: DailyReport_2024-11-15_processed.csv
Tip
When building filename patterns that include today's date, use the "Get current date and time" action first, then format the date as a string using the "Format datetime" action. This gives you reliable, sortable filenames like 2024-11-15 rather than locale-dependent formats like 11/15/2024 that break on systems with different regional settings.
"Delete file" is straightforward, but treat it with respect — there's no undo. In production automations, consider a two-stage approach: move files to a "to_delete" staging folder first, let the flow run successfully, then delete from staging. That gives you a recovery window if something went wrong.
"Get file info" retrieves metadata about a file without opening it: size, creation date, last modified date, and extension. This is useful for validation — for example, refusing to process a file that's 0 bytes or was last modified more than 24 hours ago.
The Folder group parallels the File group but operates on directories. You'll use these to:
*.csv). This is the foundation of batch processing — iterate over the list with a "For each" loop.A reliable pattern for setting up a working environment at the start of a flow:
Create folder
Folder path: C:\Automation\WorkingDir\%CurrentDate%
If folder exists: Do nothing
Get files in folder
Folder: C:\Exports\Incoming
File filter: *.csv
→ Saves file list to: %IncomingFiles%
For each %File% in %IncomingFiles%
[process each file]
This pattern — create a dated working directory, enumerate incoming files, loop — is the skeleton of probably half of all real-world file automation flows. Master it and you'll be ready for the more sophisticated scenarios covered in Automating File, Folder, and Email Operations with Power Automate Desktop.
The Clipboard group has just two actions you'll use regularly: "Get clipboard text" and "Set clipboard text." These are simple but powerful when you're working with applications that don't expose a proper UI automation interface.
The pattern is: set the clipboard to the text you want, switch focus to the target application window, then send a Ctrl+V keystroke using the "Send keys" action. It's not elegant, but it works reliably with legacy applications that don't support more structured input methods.
Warning
Clipboard-based automation is fragile in shared or attended environments. If a user is working at the machine and copies something to the clipboard between your "Set clipboard text" and "Send keys" steps, your automation will paste the wrong content. For attended RPA scenarios, consider using the "Populate text field" action from the UI Automation group instead — it writes directly to the field without touching the clipboard.
Let's walk through the flow structure for our morning file processing scenario from the introduction.
The goal: for each CSV in an incoming folder, check the file isn't empty, copy it to an archive, launch the legacy app, import the file, then close the app.
Here's the logical structure in pseudocode, using the actions we've covered:
Get current date and time → %Today%
Format datetime %Today% as "yyyy-MM-dd" → %DateStamp%
Create folder: C:\Archive\%DateStamp% (if exists: do nothing)
Get files in folder: C:\Incoming filter: *.csv → %CSVFiles%
For each %CSVFile% in %CSVFiles%:
Get file info: %CSVFile% → %FileInfo%
If %FileInfo.Size% > 0:
Copy file: %CSVFile% to C:\Archive\%DateStamp%\ → %ArchivedFile%
Run application: C:\LegacyApp\importer.exe
Arguments: --input "%CSVFile%"
After launch: Wait for application to load
→ %ImporterProcessId%
Wait for window: *Import Complete* (timeout: 60s)
Close window: *Import Complete*
Rename file: %CSVFile% to [name]_done.csv
Else:
[Log: skipped empty file]
Notice the structure: setup first (date, folder), then enumerate, then process each item with validation, then clean up. Every step has a clear purpose. The flow fails loudly at "Wait for window" if the importer doesn't complete — which is exactly the right behavior.
For a flow like this that runs every morning without human involvement, you'd want to read about Attended vs Unattended RPA to configure it properly for your environment.
Build this flow from scratch in Power Automate Desktop:
yyyy-MM-dd format.C:\PAD_Practice\Archive\[today's date]. Set "If folder exists" to "Do nothing."C:\PAD_Practice\Incoming\TestReport.txt with some sample text content.C:\PAD_Practice\Incoming\TestReport.txt is present.*TestReport* to open (timeout: 15 seconds).Run the flow. Check that the archive folder was created, the file was copied, and Notepad opened and closed cleanly. Then deliberately delete the source file and re-run — verify the "If file exists" condition branches correctly and the flow doesn't crash.
"My application launches but the next action fails immediately." You're hitting the timing problem. "Wait for application to load" only confirms the process started. Add a "Wait for window" action right after "Run application" to wait for the specific window title to appear before proceeding.
"My window title wildcard isn't matching." Window titles are exact strings — check for trailing spaces, version numbers, or document names embedded in the title. Open Task Manager and look at the Details or Processes tab to see the exact window title. You can also use the "Get windows" action to enumerate all open windows and their titles during a debugging run.
"Copy file fails with 'destination already exists.'" Change the "If file exists" setting in the Copy file dialog from the default (often "Raise error") to "Overwrite" if that's your intent, or build explicit logic to rename the file first.
"My For Each loop processes files out of order." "Get files in folder" returns files in filesystem order, which isn't always alphabetical. If processing order matters, you'll need to sort the list — which is covered in depth in the Variables, Lists, and Data Tables guide.
"The flow works on my machine but fails when run unattended." Unattended runs use a different session. Window titles, file paths, and mapped drives may differ between sessions. Check that all paths are absolute (not relative), and that the application is installed for all users, not just your profile. See Attended vs Unattended RPA for a full breakdown of these environment differences.
Note
If you find yourself building increasingly complex file-handling logic, consider whether some of that logic belongs in a subflow. Keeping "set up working directories" and "process individual files" as separate subflows makes your main flow much easier to read and maintain. Subflows and Reusable Logic in Power Automate Desktop walks through exactly how to structure this.
You now have a working mental model of three of the most important action groups in Power Automate Desktop: File, Window, and System (application launching). You understand that launching an app isn't a single step — it's a sequence of launch, wait for window, and then interact. You know how to enumerate files in a folder and process them in a loop. And you've seen how existence checks and file metadata validation make automations resilient rather than fragile.
These actions form the skeletal structure of almost every desktop automation you'll build. From here, the natural next steps are:
The action library has dozens more groups — OCR, web automation, email, databases — but every one of them follows the same pattern you've learned here: drag the action in, configure inputs, capture outputs, use those outputs in subsequent steps. The fundamentals you've built today will carry you through all of it.