Power Automate Desktop + SAP: What Breaks After the First Month (And Why)

Scenario: FI Posting Bot That Ages Badly

A finance automation team builds a Power Automate Desktop (PAD) flow:

• Input: Excel file with vendor invoices
• System: SAP GUI for Windows, classic dynpro screens
• Flow logic (simplified):
  1. Log in to SAP
  2. Open transaction FB60
  3. Loop rows in Excel, post each invoice
  4. Log out

The first month:

• Test data is clean
• Only one company code
• SAP layout is stable

By the second month:

• Another team changes the default layout in FB60
• Basis team pushes a SAP GUI update
• Finance adds new company codes and tax codes

Symptoms:

• Bot clicks the wrong fields in FB60
• Runs only on one robot VM, fails on others
• Random delays, timeouts, or SAP not found errors

Let’s break down the main causes.

1. UI Element IDs Drift When SAP Layouts Change

What actually breaks

PAD’s SAP automation for SAP GUI is UI-based. Actions like Click UI element in window rely on:

• The window title (e.g. Document Entry: Vendor Invoice)
• The control hierarchy and technical IDs exposed by SAP GUI scripting

Once another team changes the layout in FB60 (e.g. hides fields, reorders tabs, switches to a different variant):

• Some controls disappear or move
• The technical path to the field changes
• PAD can no longer match previously captured elements

Typical symptoms:

• Click UI element hits the wrong field or does nothing
• Set value in UI element throws UI element not found (depending on your error handling)

This doesn’t show up in the first month because layouts are stable and testing rarely covers:

• Alternate screen variants
• Different users with different SAP personalization

Why SAP GUI scripting makes this fragile

PAD’s SAP actions use SAP GUI scripting under the hood. SAP GUI scripting exposes controls via an object model like:

• session.findById("wnd[0]/usr/ctxtBKPF-BUKRS") for company code

If a layout change removes or renames controls, these IDs change. PAD’s recorded selectors are effectively snapshots.

Design fixes

1. Standardise layouts for bot users

   • Create a dedicated SAP user role for robots.
   • For that role, configure:
     • Fixed layout variants for FB60 and other transactions
     • No user-level personalization that hides or reorders fields
   • Document that any layout change must be regression-tested against the bot.

2. Use stable selectors, not pure positions

   • When capturing UI elements in PAD:
     • Prefer selectors that include technical IDs rather than coordinates.
     • Avoid actions that rely on mouse coordinates or relative positions whenever possible.
   • In SAP-specific actions, check that the selector uses ctxt, btn, etc. IDs, not just screen index.

3. Add layout self-check steps

   • Before posting invoices, add a short validation step:
     • Read the label next to the target field (e.g. Company Code) using Get text from UI element.
     • Verify it matches expected text.
     • If not, fail fast with a clear error and stop instead of posting into the wrong field.

4. Treat layout changes as code changes

   • Include SAP screen variants in change management:
     • Any change to transaction layouts triggers bot regression tests.
     • Finance teams know that layout tweaks can break automation.

2. Bots Tied to One VM: SAP GUI, Scripting, and Display Differences

What actually breaks

In month one, the bot runs only on a single VM where it was developed. After expansion to more robots or moving to another environment, you see:

• SAP GUI doesn’t open or script
• PAD actions throw Cannot connect to SAP or UI element not found
• Same flow works on dev VM, fails on prod VM

Key causes:

1. SAP GUI scripting disabled on some machines

   • SAP GUI scripting has two levels:
     • Server-side (profile parameter sapgui/user_scripting on the SAP system)
     • Client-side (SAP GUI Options → Accessibility & Scripting → Scripting)
   • It can be enabled on one SAP system and not another, or on one client and not another.

2. Different SAP GUI versions or patch levels

   • PAD SAP actions are documented to support specific SAP GUI versions.
   • Upgrades or mismatched versions across VMs can change control behaviour or timing.

3. Display scaling and resolution differences

   • High DPI scaling (e.g. 125%, 150%) can affect window size and sometimes the way UI elements are detected.
   • Flows that rely on window positions or screen coordinates break when resolution changes.

Design fixes

1. Standardise SAP GUI and scripting across robot VMs

   • On all robot machines:
     • Install the same SAP GUI version and patch level.
     • Enable client-side scripting in SAP GUI Options.
   • On the SAP system:
     • Ensure server-side scripting is enabled for the relevant clients.
   • Test the bot against each SAP system it will touch (e.g. DEV, QA, PROD) with the same PAD version.

2. Avoid coordinate-based actions

   • Use Click UI element in window with captured selectors rather than Click at coordinates.
   • If you must use coordinates (e.g. non-standard custom controls), isolate them:
     • One dedicated subflow per screen
     • Separate test case whenever resolution or scaling changes.

3. Lock robot VM display settings

   • Configure robots with:
     • Fixed resolution (e.g. 1920x1080) across all machines
     • DPI scaling set to 100% where possible
   • Document that changes to display settings require bot regression tests.

4. Include environment pre-checks in the flow

   • At the start of the flow:
     • Verify SAP GUI is installed by checking for the executable path.
     • Optionally run a simple SAP scripting test: open a known transaction and read a field.
   • Fail early if environment is misconfigured instead of letting the main posting loop crash mid-run.

3. Timing, Locking and Month-End Load

What actually breaks

During normal days the bot runs fine. At month-end, when SAP is under heavy load and more users are online:

• PAD actions time out waiting for screens
• SAP shows short dumps or locks
• Bot posts duplicate invoices or skips rows because it misinterprets slow responses as errors

Causes:

1. Assuming fixed delays are enough

   • Many first-generation SAP bots use Wait actions (e.g. wait 1 second after each screen change).
   • Under heavy load, screen rendering can exceed these fixed delays.
   • PAD executes the next action before SAP is ready, causing UI element not found or wrong control interaction.

2. No robust handling of SAP messages and locks

   • SAP may show:
     • Error messages (red) in the status bar
     • Warning messages (yellow) that still allow posting
     • Lock messages when another user holds the document
   • Bots that don’t read and interpret these messages will:
     • Assume success when posting actually failed
     • Loop with retries that create duplicates

3. No transaction-level isolation or idempotency

   • If a bot crashes mid-run, re-running the same batch without checking SAP state can double-post.

Design fixes

1. Use wait-for-element, not fixed sleeps

   • Replace generic Wait actions with:
     • Wait for window or Wait for UI element to appear with reasonable timeouts.
   • This aligns bot timing with actual SAP behaviour instead of assumptions.

2. Read and interpret SAP status messages

   • After each posting:
     • Use Get text from UI element on the SAP status bar.
     • Parse the message:
       • If it contains a known success pattern (e.g. document number created), mark the invoice as posted.
       • If it contains a lock or error message, handle it explicitly (log, retry, or skip).
   • This turns SAP messages from noise into control flow.

3. Design for idempotency at batch level

   • Before posting a document:
     • Check in SAP whether the combination of vendor, amount, and reference already exists.
     • If found, treat it as already processed and skip.
   • This avoids duplicates when the bot is re-run after failure.

4. Test under realistic load

   • Don’t only test at 10:00 with low SAP usage.
   • Schedule a pilot run close to month-end with:
     • Realistic posting volume
     • Normal user load
   • Use logs to identify where waits and status handling need tightening.

4. Data Quality Assumptions That Don’t Survive Finance Reality

What actually breaks

In the first month, test data is curated. Later:

• Excel input contains new company codes, tax codes, or missing fields
• Bot tries to post values SAP rejects
• Error handling sends everything to a generic failure bucket, making support painful

Key patterns:

1. Hard-coded company code or posting keys

   • Bot assumes one company code, one posting pattern.
   • New entities or changes in posting logic require code changes and retesting.

2. Minimal validation before SAP

   • Bot pushes raw Excel data into SAP and lets SAP handle validation.
   • Errors are discovered only after SAP rejects the posting.

Design fixes

1. Separate data validation from SAP posting

   • Add a pre-processing subflow that:
     • Checks required fields (vendor, amount, company code, tax code) are present.
     • Validates simple rules (e.g. non-negative amounts).
   • Only pass validated rows to the SAP posting subflow.

2. Parameterise company code and posting logic

   • Store company code, posting keys, and tax code mappings in a configuration source:
     • A table in Excel, a database, or a PAD data table.
   • Read configuration at runtime instead of hard-coding values in the flow.
   • This reduces changes needed when finance adds entities.

3. Log per-document outcomes clearly

   • For each invoice, write to an output log:
     • Input data
     • SAP document number (if posted)
     • SAP status message
     • Error category (validation error, SAP error, lock, etc.)
   • This makes support and reconciliation tractable when things go wrong.

5. Governance: Keeping SAP RPA Alive Beyond Month One

The technical fixes above only work if the organisation treats SAP RPA as a product, not a one-off script.

Practical governance steps for finance and ERP teams:

1. Define SAP RPA ownership

   • Assign clear ownership for:
     • PAD flow maintenance
     • SAP layout and scripting configuration
     • Robot VM configuration
   • Without this, layout changes and upgrades happen without considering bots.

2. Version and test flows deliberately

   • Use source control or PAD’s environment structure to track versions.
   • For any change in:
     • SAP GUI version
     • SAP transaction layout
     • Robot VM configuration
   • Run a defined regression suite on key transactions (FB60, F-02, etc.).

3. Monitor and alert on SAP bot runs

   • Log:
     • Start/end times
     • Number of documents processed
     • Error counts by category
   • Use these logs to spot degradation early (e.g. increasing timeouts around month-end).

One Concrete Takeaway: Lock Down the Screen Before You Add More Logic

If your current SAP PAD flow is already in production, the most effective single improvement is:

• Create a dedicated SAP role and layout for the bot user, enable scripting consistently, and then refactor the flow to rely on stable UI selectors and status messages instead of coordinates and fixed waits.

Do this before adding more transactions or complexity. A stable, predictable SAP screen and scripting environment is the difference between a bot that quietly runs for years and one that starts breaking right after the first month.