Power Automate Desktop in Production - RPA That Actually Works

Robotic Process Automation has been hyped for years. Every vendor promises bots that will transform your business. Most implementations I've seen deliver disappointing results - brittle automations that break constantly and require more maintenance than they save.

Power Automate Desktop is different. Not because the technology is fundamentally better, but because the economics and integration story make it practical for mid-market companies like Julius Silvert. Here's how we're using it in production.

Why We Started with PAD

We have legacy systems that will never have modern APIs. Our VAI S2K ERP runs on an AS/400 and communicates primarily through green screen terminals. Some of our vendor portals are ancient web applications with no API access. Some of our customers send orders via email in formats that resist automated parsing.

Historically, we've handled these integration gaps with human labor. Someone logs into the vendor portal and copies data into our system. Someone reads the email order and manually enters it. These are exactly the repetitive, rule-based tasks that RPA should handle.

We evaluated UiPath and Automation Anywhere. Both are capable platforms, but both have enterprise pricing that's hard to justify for a $110M company. Power Automate Desktop, included with our Microsoft 365 E3 licenses (with some limitations) and reasonably priced for premium features, hit the sweet spot.

Our Production Automations

Vendor Portal Data Extraction

One of our major vendors publishes daily pricing updates on a web portal. No API, no file export, just a web table that updates at 6 AM. For years, someone on our team logged in every morning, copied the data, and pasted it into Excel for import into S2K.

Now a PAD flow does it:

1. Opens Chrome, navigates to the portal
2. Logs in with stored credentials
3. Navigates to the pricing page
4. Extracts the table data
5. Saves it as a CSV
6. Triggers a Power Automate cloud flow that imports the data

This runs unattended at 6:15 AM every day. It's saved about 30 minutes of daily manual work and eliminated the errors that came from copying and pasting.

Customer Order Processing

A subset of our customers send orders via email in inconsistent formats. They're not going to change - they're long-standing accounts with established workflows, and accommodating their quirks is part of customer service.

We built a PAD flow that:

1. Monitors a specific mailbox for incoming orders
2. Uses OCR and text extraction to identify order details
3. Matches product names to our SKUs using fuzzy matching
4. Creates draft orders in our system
5. Flags anything it's uncertain about for human review

This isn't fully autonomous - about 20% of orders need human intervention because of ambiguous product names or unusual requests. But 80% go through with minimal touch, and even the flagged ones are partially populated.

S2K Green Screen Automation

This is where PAD really shines for us. VAI S2K has a terminal emulator interface - no modern UI, no API, just keyboard navigation and screen scraping.

We use PAD to automate routine S2K tasks:

• Bulk price updates that would take hours to enter manually
• Customer record updates from spreadsheets
• Inventory adjustments based on physical counts
• Report generation and export

The terminal automation is surprisingly robust. PAD sends keystrokes, waits for screen changes, reads specific screen positions, and handles the navigation that S2K requires. It's not elegant, but it works.

What Broke (And How We Fixed It)

RPA is fragile by nature. You're automating based on UI elements that change. Here's what broke for us:

Vendor portal redesign: The vendor whose pricing we scrape redesigned their portal in June. Our flow broke completely. We had to rebuild the UI interactions from scratch. Fortunately, PAD's recorder made this faster than it would have been with code-based automation, but it still took half a day.

Lesson: Budget for regular flow maintenance. UI-based automation will break when UIs change. We now check our flows monthly for subtle changes that might cause problems.

Chrome updates: A Chrome update in March changed how the browser reported certain elements. Our flows that used CSS selectors started failing intermittently. We had to switch to different selector strategies (XPath in some cases) to restore reliability.

Lesson: Don't assume browser automation is stable. Test after every browser update. We now delay Chrome auto-updates on our automation machines by two weeks to give us time to test.

Screen resolution sensitivity: One flow worked perfectly on the developer's machine but failed on the production machine. The production machine had a different screen resolution, and some click coordinates were off. We rebuilt the flow using element-based clicking instead of coordinate-based.

Lesson: Always use element-based interactions, never coordinates. Coordinates are brittle. Elements are more resilient to layout changes.

Authentication timeouts: Our S2K automation started failing after a few hours because the terminal session timed out. We hadn't accounted for long-running processes that might span session lifetimes.

Lesson: Build session management into your flows. Check if you're logged in before proceeding. Re-authenticate if necessary. Don't assume sessions persist.

Attended vs. Unattended

Power Automate Desktop supports both attended (user triggers the flow) and unattended (scheduled, runs without user) execution. We use both.

Attended uses:

• Ad-hoc bulk updates triggered by users
• Report generation on demand
• Complex data entry assistance (user verifies each step)

Unattended uses:

• Scheduled data extraction (vendor pricing)
• Email order processing (runs continuously)
• Overnight batch processing

Unattended requires premium licensing and dedicated machines (or VMs). We run our unattended flows on a dedicated VM that nobody else uses. This prevents conflicts with human users who might interfere with the automation.

Integration with Cloud Flows

The real power of PAD comes from integration with Power Automate cloud flows. Desktop flows handle the UI automation; cloud flows handle everything else - email processing, data transformation, notifications, error handling.

Our typical pattern:

1. Cloud flow triggers on schedule or event
2. Cloud flow calls desktop flow to interact with legacy system
3. Desktop flow returns data or status
4. Cloud flow processes the data, sends notifications, logs results

This separation keeps the desktop flows focused on UI automation while the cloud flows handle orchestration. It also makes error handling cleaner - if the desktop flow fails, the cloud flow can retry, alert someone, or take alternative action.

ROI Reality Check

Let's be honest about ROI:

Vendor pricing extraction: 30 minutes/day × 250 working days × $30/hour = $3,750/year saved. Development time was about 8 hours. Clear positive ROI.

Email order processing: Harder to quantify. Reduced errors, faster processing, but still needs human oversight. Probably saves 5-10 hours/week. Development time was about 40 hours. Positive ROI within a few months.

S2K automations: Varies wildly by task. Bulk price updates that used to take 4 hours now take 30 minutes of setup plus unattended execution. Complex automations save significant time; simple ones might not justify the development effort.

The overall pattern: automations that run frequently and handle high-volume tasks have clear ROI. Automations for occasional tasks often don't - the development time exceeds the time savings.

We use a simple rule: if the automation won't save at least 10 hours per month, we don't build it. That threshold ensures the development investment pays back within a few months.

Governance and Maintenance

RPA creates technical debt. Every flow is code that needs maintenance. We've established governance practices:

Documentation requirements: Every production flow has a one-page document explaining what it does, what it depends on, and how to troubleshoot common failures.

Source control: Flow definitions are exported and stored in our Git repository. We can track changes and roll back if needed.

Monitoring: Cloud flows send alerts when desktop flows fail. We review failure logs weekly.

Ownership: Each flow has an assigned owner responsible for maintenance. When people leave, ownership transfers explicitly.

Quarterly review: Every quarter, we review all production flows. Is it still needed? Is it still working correctly? Should it be rebuilt or retired?

When Not to Use RPA

RPA is a tool for specific situations. We explicitly don't use it when:

APIs are available: If there's an API, use it. APIs are more reliable, faster, and easier to maintain than UI automation.

The process should change: Sometimes the right answer isn't automating a bad process - it's fixing the process. RPA can cement bad practices.

The UI changes frequently: If the target application updates weekly, you'll spend more time maintaining the automation than you save.

The task requires judgment: RPA handles rules-based work. If the task requires interpretation or decision-making, it's not a good fit.

Looking Ahead

Microsoft is investing heavily in PAD. Recent updates have improved reliability, added better AI capabilities (OCR, document understanding), and improved the cloud flow integration.

We're planning to expand our PAD usage in 2025:

• AI Builder integration for more intelligent document processing
• Additional vendor portal automations
• Customer portal automations (for customers who prefer portals over EDI)
• More S2K tasks as we prepare for D365 migration (automating data extraction for the migration itself)

The goal isn't to automate everything - it's to automate the right things. The boring, repetitive, error-prone tasks that humans shouldn't be doing manually. That's where RPA delivers real value.