Automating Data Entry Into Legacy Core Systems With Power Automate for Desktop — Replacing Manual Entry From Excel and Paper With UI Automation

“Every day, staff retype orders that arrive through a web form or by email into our in-house sales management system by hand.” “Transcribing a month’s worth of attendance and request data from Excel into the core system at month-end takes two full days.” We hear complaints like these all the time. What they have in common is that the destination system is an old business application that has been in use for ten or twenty years — a WinForms or VB6-era screen, a dedicated client — with no API and no CSV import feature.

Modifying the system would fix the problem at its root, but it is not unusual for manual entry to persist because the original vendor is gone, the source code no longer exists, or the cost of modification just does not pencil out. A practical tool for filling that gap is UI automation with Power Automate for desktop (PAD). Because it simply reproduces the keyboard input and mouse operations a person would perform, you can automate the work without touching the destination system at all. On Windows 11 there is also the convenience of being able to try it with no additional installation.

That said, UI automation is also a tool where “getting it running the first time is easy, but keeping it running reliably is hard.” This article focuses specifically on data-entry work, covering everything from whether you should even choose UI automation in the first place, through the boundary between what is free and what needs a license, to designs for stable operation and recovery from failures. We covered the general question of when to use which part of Power Automate, and error handling in general, in Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling; this article is the specific case study for data-entry work.

1. The Bottom Line First

• UI automation is the last resort. Before reaching for it, look for whether the destination system offers a CSV import, direct database insertion, an API, or file-based integration. If even one of those exists, it will be more reliably stable than UI automation.
• PAD comes built into Windows 11, and can also be installed for free on Windows 10. With the recorder and over 400 actions, you can build a no-code flow that reads Excel and types the data into a screen.¹²
• Building a flow and running it yourself (attended execution) costs nothing extra. This holds whether you sign in with a work/school account or a Microsoft account. Automatically launching from a cloud flow, scheduled runs, and sharing flows, on the other hand, all require a Power Automate Premium license.³⁴
• Unattended execution — the kind you would use for an overnight batch job — additionally requires machine registration and a Power Automate Process license. There are also technical prerequisites specific to it, such as requiring that every user be signed out.⁵⁶
• The keys to stable operation are three things: how you build selectors, waiting for elements, and per-record error handling. A flow built out of nothing but fixed Wait actions is guaranteed to break eventually.⁷⁸⁹
• So that you can tell how far the entry got if it fails, build in, from the very start, a design where the source Excel file has a status column and a registration-number column that get written back after each record. That way, re-running the flow never causes duplicate entries.
• Because the fate of eventually breaking when the screen changes never goes away, work with a high volume, work that cannot tolerate downtime, or work against an app that updates frequently belongs to the domain of data-integration development or core-system modification. We lay out where to draw that line in Chapter 8.

2. What’s Actually Wrong With Data-Entry Work

Transcribing data from Excel or paper into a core system carries problems that go well beyond “simple work eating up time.” Three issues come up again and again in the consultations we get.

• Time gets concentrated around the closing date. Daily order entry is at least spread out, but month-end invoice processing and attendance tallying end up concentrated into the one or two days right after the closing date. During that window, staff can barely do anything else. Most companies are almost certainly absorbing this with overtime or extra help.
• Entry mistakes flow downstream. A mistyped digit, a row that shifted, a mixed-up product code. Transcription errors do not surface until they have turned into a wrong invoice or a wrong inventory count, so the effort of investigating the cause and correcting it ends up many times the effort of the original mistake. Adding a double-check reduces mistakes, but it also adds time.
• The work becomes something only that one person can do. Know-how like “this screen throws an error unless you enter things in this order” or “this one customer needs a special way of entering data” accumulates in that person’s head, and the work grinds to a halt if they are out.

The value of automation is not limited to saving time. A flow only ever enters data exactly the way it was told to, so transcription mistakes disappear, and because the procedure is preserved in a tangible form as a flow, it also eases the “only one person can do this” problem. Being able to flatten out the spike around the closing date matters a lot too.

One note: if the source is paper or a fax, there is a “reading” step that has to happen before any of this — OCR for faxed order forms, for instance, is its own topic. This article proceeds on the assumption that the source has already become data, such as an Excel file.

3. Choices for Automation — UI Automation Is the Last Resort

The first thing I want to stress is that automating screen operations (UI automation) is the last option on the list. UI automation depends on “display-layer concerns” — screen layout, resolution, response speed — so no matter how carefully you build it, it is unavoidably more fragile than a method that hands data over directly. Check first whether the destination core system offers any of the following.

The other option is to head in the direction of “eliminating” the transcription altogether — that is, modifying or rebuilding the core system itself. We cover decisions like adding an import feature to a VB6 app, or going all the way to a web-based rebuild of the order-entry front end, in How Long Will VB6 Apps Keep Running? — Runtime Support Status and a Practical Path to .NET Migration and When Not to Move a Windows App to the Web: A Decision Table and the Practical Answer of Splitting. Since modification costs development budget, it is also realistic to automate with PAD first to buy time, then invest in the modification once the volume of work grows and you can see the limits of automation.

4. The Basics of Power Automate for Desktop

Getting Started Has a Low Barrier

PAD comes built into Windows 11. Search “Power Automate” in the Start menu, and you will find the app; on first launch it downloads automatically and you are ready to go.² Windows 10 and Windows Server 2016 also carry usage rights, and you can install it for free from the Download Center.² There are two installation methods — a Microsoft Store version and an MSI installer version — and if you are planning ahead to the cloud integration (machine registration) discussed later, choose the MSI version, since it lets you install the machine runtime app alongside it.¹⁰

Building the Skeleton With the Recorder

PAD has a recorder that records your operations and converts them into a sequence of actions. It records mouse and keyboard operations in relation to UI elements, which makes it perfectly practical for building the skeleton of a data-entry flow. What matters for data-entry work specifically is that you can choose between two recording methods, UIA (UI Automation) and MSAA (Microsoft Active Accessibility). UIA is the recommended method for relatively newer apps such as WPF or WinForms, while MSAA is the method for old apps — like VB6 or classic Win32 — whose elements UIA cannot pick up. If elements in an old core-system screen will not grab properly, switching the recorder’s recording mode to MSAA can sometimes fix it.¹¹

That said, the recorder is only for the skeleton. It cannot record conditional branches or loops, so the assumption is that you will finish the flow by editing it in the designer afterward.¹¹

UI Elements and Selectors

PAD remembers buttons and text boxes on the screen as “UI elements.” What that actually is, underneath, is a selector that identifies the element through a combination of the window hierarchy and its attributes. The lifespan of a data-entry flow is decided almost entirely by how well those selectors are built. If a selector contains a sequential index or a dynamically changing ID, it can suddenly stop grabbing the element one day even though the screen looks identical. Change attributes whose values change from Equals to Contains or a regular expression, set up backup selectors with fallback for important operations, and use the Repair Selector feature to generate repair candidates when one breaks. This is the same basic approach we covered in the general guide.⁷

There is one caution specific to data-entry work. UI automation actions operate on the assumption that the target window is in the foreground, and if it is not, they bring it to the foreground automatically.¹² In other words, the PC running the flow is, in effect, “reserved exclusively for the flow.” Avoid running the flow on a PC where staff are simultaneously doing other work, since that is a recipe for stray clicks and stray input.

The Basic Shape of Data Entry: Read From Excel, Write to the Screen

The basic shape of a data-entry flow is “read with an Excel action → loop and write one record at a time with UI operations.” Open the file with Launch Excel, and read a range with Read from Excel worksheet, which becomes a data table variable. Turning on the “first row as column names” option lets you reference values by column name later in the loop, like CurrentItem['CustomerCode'], which makes the flow more resilient to column reordering.¹³ Use Write to Excel worksheet to write results back. If you want to append to the end of the rows, you can locate an empty row with Get first free row on column.¹³

5. What’s Free and Where the License Boundary Sits

The question that always comes up when deciding whether to adopt PAD is “how far is free, and where does it start costing money?” The boundary sits between “building it and running it by hand” and “running it automatically and managing it as an organization.”

Building flows and running them manually costs nothing extra with any account type.³⁴ With a Microsoft account, flows are saved to OneDrive; with a work/school account, they are saved to Dataverse in the default environment. If you are using this at a company, starting with a work account is the standard choice, with an eye toward managing it later.⁴

You cross the boundary the moment you want the flow to run without a person pressing a button. Launching a desktop flow at a fixed time or on an event requires configuring it to be called from a cloud flow, and that takes the following preparation.¹⁴

1. Machine registration: register the PC that will run the flow with the Power Automate cloud. Signing in with the machine runtime app included in the MSI version registers it. Note that the Home editions of Windows 10/11 do not support this direct connection.¹⁰
2. Desktop flow connection: create a connection (Windows account credentials) that lets the cloud flow sign in to that machine.¹⁴
3. License: the user who creates the connection must hold a license appropriate to the execution mode.¹⁴ Running it on a PC where a person is signed in — attended execution — requires Power Automate Premium (a user license that includes attended RPA rights).¹⁰⁶
4. Unattended execution additionally requires assigning a Power Automate Process license to the machine. A Process license attaches to the machine (or the flow), not to a user, and gets you one unattended execution slot (an unattended bot) per machine. One thing to watch out for: the machine you assign a Process license to must already have been registered by a user who holds a Premium license. In other words, buying only a Process license will not let you configure anything if there is no Premium user.⁵⁶

To sum up: an operation where “the person in charge presses the button in the morning and watches the data entry run in front of them” completes entirely within the free tier. An operation where “it is just finished on its own by the middle of the night” requires Premium plus Process (plus a registered machine). If the data-entry work takes around 30 minutes a day, it is plenty to start with free attended execution and consider going unattended only once the volume grows. The full picture of Power Automate licensing — including where the line falls between standard and premium connectors — is a topic worth covering separately.

6. Designing for Stable Operation

Wait for the Element, Not a Fixed Delay

Old core systems have search and registration response times that swing wildly depending on load. A flow tuned with a fixed Wait like “wait 3 seconds” is guaranteed to break on a day the system is slow. The basic approach is to use the Wait for window content action to “wait until a specific UI element or text appears (or disappears).”⁸ Getting a window (Get window) also lets you set a timeout, letting you choose between “fail after N seconds if not found” or “wait until it appears.”⁸ Waiting until the registration-complete message appears before moving on to the next row is especially important in a data-entry flow. If you start the next entry without waiting, the screen switches over before the previous row’s registration has finished, and the data gets mixed up.

Build Error Handling Per Record

The standard practice for error handling in a data-entry flow is to wrap one record’s worth of work inside the loop in an On Block Error block, rather than wrapping the whole flow. When an error occurs, record what failed for that row, return the screen to its initial state (close the entry screen and go back to the menu, etc.), and move on to the next row. That way, even if 1 out of 100 records has a wrong product code, the other 99 finish entry, and only the one that failed is left for a person to handle. You can also combine this with per-action retry settings for transient errors, such as slow responses.⁹ For the finer points of error handling — retrieving the error with Get last error, designing the cleanup step, and so on — see the general guide and Error Handling and Retry Design in Power Automate.

Make It Possible to Tell “How Far It Got” Even If It Fails

UI automation has no transactions the way a web system does. If a flow dies partway through and you cannot tell “which rows are already registered in the core system,” you are left with two options: re-running and causing duplicate entries, or manually cross-checking every single record. There are two designs that prevent this.

1. Give the source Excel file a status column. Prepare a status column with values like “not processed,” “in progress,” “complete,” and “error,” plus a column for the registration number issued by the core system. Set a row to “in progress” before you start entering it, confirm registration completion on screen and read the registration number, and then write back “complete” plus the registration number. Since the flow only ever targets rows still marked “not processed,” it never touches already-entered rows no matter how many times you re-run it (re-run safe).
2. Only rows left stuck at “in progress” need a human to check them. If a flow is going to die, it dies mid-entry, so the only rows under suspicion are the ones marked “in progress.” You only need to check the core system for that one row before re-running, which shrinks the cross-check scope from 100 records down to one.

This status column also doubles as a run record. Whether “yesterday’s transcription all finished” can be answered by opening Excel, without even looking at the flow’s run history — a form that is easy to explain on the ground.

Pitfalls of the Unattended Environment

We get a genuinely large number of consultations about flows that worked fine under attended execution but stopped working the moment they went unattended. The cause is almost always a difference in the environment.

• Session prerequisites: for unattended execution, Power Automate creates a new remote desktop (RDP) session on the target machine and signs out after execution finishes. While it is running, the screen on the target machine stays locked. As a prerequisite, every user on the machine must already be signed out — on Windows 10/11, if anyone’s session remains (even locked), execution fails. On Windows Server, an error occurs if a locked session for the same user as the connection remains. If your habit after maintenance work is to step away by “locking” or “disconnecting” rather than signing out, the nightly flow will stop. Always sign out is the watchword.⁵
• Permissions: the user used for the connection must be able to create an RDP session on that machine (usually by belonging to the Remote Desktop Users group). Also, unattended execution does not support operations that involve elevating to administrator privileges.⁵
• Screen resolution: the default resolution of an RDP session can differ from the screen the flow was built on. If the resolution is lower, UI elements that were visible while building the flow end up hidden off-screen, causing “element not found” failures, or a coordinate-based operation ends up clicking somewhere else.⁵ As a countermeasure, you can pin the “screen resolution for unattended runs” in the flow’s properties to the same value used when it was built.¹⁵ Differences in DPI scaling cause the same kind of failure, so it is safest to keep it at 100% both when building and when running.¹⁶

Once you have verified all of this, set up the scheduled trigger (e.g., running every weekday morning at 6 AM) on the cloud-flow side. We cover scheduling design that includes business-day checks and month-end processing in Designing Scheduled Flows and Business-Day Logic in Power Automate.

7. An Example Design for a Data-Entry Flow

Combining the pieces covered so far, here is what a typical data-entry flow looks like when designed as “order-list Excel file → the core system’s order-entry screen → write the result back to Excel.”

flowchart TD
    Start([Start: manual or triggered from a cloud flow]) --> ReadX[Read from Excel worksheet<br/>Read the order list, first row as column names]
    ReadX --> Filter{Are there any rows with status not processed?}
    Filter -- No --> Report[Tally results and log/notify] --> End([End])
    Filter -- Yes --> Launch[Launch the core system and log in<br/>Confirm the menu screen appears by waiting for the element]
    Launch --> Loop[Loop through unprocessed rows one at a time<br/>Wrap the loop body in On Block Error]
    Loop --> Mark[Update status column to in progress]
    Mark --> Entry[Open the order-entry screen and enter the fields<br/>Wait for window content on each screen transition]
    Entry --> Confirm[Registration button → wait for completion message<br/>Read the issued registration number from the screen]
    Confirm --> WriteBack[Set status column to complete and write back the registration number]
    WriteBack --> Loop
    Loop -. An error occurs on one record .-> Handler[Record the error details on that row<br/>Failures before registration become error / failures after registration stay in progress<br/>Return the screen to the menu and move to the next row]
    Handler --> Loop
    Loop -- All records processed --> Close[Log out of the core system and close it] --> Report

A few notes on the design.

• Validate input values before any UI operation. Product code digit counts, whether a numeric field has text mixed in, missing required fields — validate these on the flow side right after reading Excel, and mark any row that looks wrong as “error” before it ever touches the core system. Rejecting bad data upfront is many times more stable than trying to handle the core system’s error dialogs through UI operations.
• Only a failure that happens before the registration button is pressed is allowed to be marked “error.” If your error handling uniformly rewrites the status column to “error,” you will also mark as “error” a row that failed after the registration button operation already succeeded (say, while waiting for the completion message or while writing back), which sets up an accident where staff re-run that row and it gets registered twice in the core system. For failures that happen after the registration operation, leave the status column at “in progress”; never target rows left at “in progress” for re-run, and instead have a person cross-check with the core system whether it was actually registered before manually setting it back to “complete” or “not processed.” The point of this design is not to eliminate ambiguity — it is to route the ambiguous cases to a human for confirmation, deliberately, rather than guessing.
• Anticipate on-screen error dialogs. Entry-time errors (insufficient stock, a customer credit-check error, etc.) still happen even so. Catch any dialog you can anticipate with a “does the window exist” conditional branch, record it as that row’s error detail, and leave anything unanticipated to On Block Error.⁹
• Keep a rough sense of volume and time. It is not unusual for UI automation to take tens of seconds per record. If 100 records take an hour, that fits comfortably within an overnight unattended run, but if there are several thousand records every day, that is a sign to reconsider UI automation as a method at all (next chapter).
• Finish normalizing the source data upstream. Pitfalls that come from CSV/Excel — character-encoding variance, inconsistent date formats, a mix of full-width and half-width characters — are covered in CSV Is Not “Just Text”: A Practical Guide to CSV Handling in C# Business Apps (Encoding, Excel Compatibility, Injection Defense).

8. How Far Should You Go With PAD?

UI automation breaks eventually, whenever the screen changes. That is not something design can fix — it is the fate of the method itself. That is exactly why you need to have a clear line between “data entry it is fine to automate with PAD” and “data entry that should move on to development or modification.”

As a rule of thumb for the judgment, I use: “if this flow stayed broken for a week, would the business still function by falling back to manual entry?” If it would, PAD automation has plenty of value. If it would not, that transcription work is no longer an “automation” requirement — it is a “system integration” requirement, and it is time to consider adding an import feature, database integration, or even digitizing order processing itself (see What Is EDI? How It Streamlines Business-to-Business Ordering — From Fax, Email, and Manual Entry to Data Integration or Moving FAX Orders to the Web — Designing the Dual-Operation Period and a Phased Migration).

One more thing: PAD flows themselves also tend to become “assets only the person who built them can touch.” Who takes over the flow’s contents, its connections, and the machine it runs on is a governance question worth designing deliberately from the start, rather than as an afterthought.

9. Summary

Transcription into a core system with no API and no CSV import can be automated “without touching the system itself” using PAD’s UI automation. On Windows 11 you can start using it out of the box, and building it and running it yourself costs nothing extra. Just freeing staff from an hour of daily data entry, and eliminating the investigation and correction of transcription mistakes, is more than enough to pay back the effort of adopting it.

The important thing, though, is getting the order and the design right. Look for a CSV import, database, API, or file integration before reaching for UI automation. Start with free attended execution, and understand the prerequisites for going unattended: Premium plus Process licenses, and a signed-out machine. Stabilize with selectors, waiting for elements, and per-record error handling, and always preserve “how far it got” by writing back the status column. And once the volume, criticality, or the frequency of screen changes exceeds what UI automation can handle, do not force it to keep growing — switch to modifying the core system or developing data integration instead.

We take on consultations covering the whole continuum, from design reviews of PAD-based data-entry automation through to contract development of import features and inter-system integration, and legacy-app migration. Feel free to reach out even at the “can this even work with our core system?” stage.

Related Articles

• Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling
• How Long Will VB6 Apps Keep Running? — Runtime Support Status and a Practical Path to .NET Migration
• When Not to Move a Windows App to the Web: A Decision Table and the Practical Answer of Splitting
• Error Handling and Retry Design in Power Automate
• CSV Is Not “Just Text”: A Practical Guide to CSV Handling in C# Business Apps (Encoding, Excel Compatibility, Injection Defense)

Related Consulting Areas

Komura Software LLC handles everything from consulting on the design and stabilization of data-entry automation with Power Automate for desktop, through to data-integration development and legacy-app modification for core systems that go beyond what UI automation can handle.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is Power Automate for desktop free to use?

Yes. The Power Automate app comes built into Windows 11, and it can also be installed for free from Microsoft's Download Center on Windows 10. Work/school accounts get the whole set of flow-building and manual (attended) execution features — the recorder, 400+ actions, error handling — at no extra cost. However, launching from a cloud flow automatically, sharing flows, and centralized run-log management all require a paid Power Automate Premium license.

What do I need to run a data-entry flow overnight or early in the morning with nobody around?

Unattended execution requires a setup where a cloud flow calls it, which in turn requires registering the target machine, creating a desktop flow connection, and assigning a Power Automate Process license to the machine. Registering the machine itself must also be done by a user holding a Premium license. On the technical side, unattended execution runs by creating a new remote desktop session, so every user on the target machine must already be signed out — if even one locked session remains, execution fails on Windows 10/11.

I've heard UI automation is fragile. Is it actually practical?

It's practical as long as the target core system's screens are stable. Most of what breaks comes down to how UI elements are identified (selectors) and insufficient waiting, so stability improves a great deal with designs like changing attributes that vary into Contains or regular-expression matches, setting up backup selectors, and waiting for an element to appear instead of using a fixed delay. That said, the fate of eventually breaking when the screen layout changes never fully goes away, so if the target app updates frequently, or if the volume or importance of the work means downtime is unacceptable, you should consider data-integration development or modifying the core system itself rather than UI automation.

If a data-entry flow fails partway through, won't we lose track of how far it got?

That can be prevented with the right design. The key is to give the source Excel file a status column (not processed / in progress / complete / error) and a registration-number column, and to check the core system's registration result and write the status back after each record is entered. That way, if it fails, the Excel file itself retains exactly which rows are already registered, and re-running the flow only ever targets rows still marked 'not processed,' so duplicate entries never happen. Handling errors per record — logging the failed row and moving on to the next one — also means a single input mistake doesn't halt the whole run.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.