**SAP WebGUI Automation Step-by-Step Fix (No Code)**
**First, understand what’s actually broken**
Your symptoms point to two separate problems, and neither is a timing problem. That’s why adding delays didn’t help.
**Problem 1 - The browser is leaking, not SAP.** SAP WebGUI leaves behind orphaned page elements and background scripts every time a screen changes. Logging out of SAP clears your SAP session but does nothing to clean the browser’s own memory. So the browser gets heavier with every queue item until it starts stalling. The slowdown tracks how long the browser has been open, not what SAP is doing.
**Problem 2 - You’re waiting for the element to exist, not to be ready.** SAP draws the screen first, then wires up the buttons a moment later. UiPath sees the button the instant it’s drawn - before it can actually respond. On top of that, SAP puts an invisible “loading” layer over the screen that swallows clicks even when you can’t see it. This is exactly why Debug says “element found” and the click still does nothing.
Sleeping for 7 seconds doesn’t make an unwired button become wired, and it doesn’t tell you when the invisible layer is gone. That’s why the delay approach fails no matter how high you push it.
**Step 1 - Confirm the memory leak**
Log the Chrome memory usage every five queue items. If the number climbs steadily and never drops, you’ve confirmed Problem 1. This takes ten minutes and tells you whether the rest of this applies.
**Step 2 - Stop logging out after every item**
Logging out costs you 8 to 15 seconds per item and doesn’t reclaim any browser memory. Remove it. Keep the SAP session alive and instead return to a clean home screen between items by sending the “/n” command into the OK-code field.
**Step 3 - Recycle the browser on a counter**
Instead of logging out per item, fully rebuild the browser every 40 queue items. The full recycle sequence is:
1. Send “/nex” in the OK-code field to exit SAP cleanly and release any locks
2. Close the browser
3. Kill any leftover Chrome processes still running in the background
4. Delete the browser profile folder entirely
5. Relaunch the browser, log back into SAP, run a health check
6. Reset your counter to zero
Also trigger this early if browser memory crosses roughly 1.2 GB, or if two transactions fail back to back.
Critical detail: only recycle **between** queue items, never in the middle of one. Recycling costs about 30 seconds, but spread across 40 items that’s under one second each. Compare that to 8–15 seconds every single item for logout.
Start with 40 as your threshold and tune it. Plot memory against transaction count, find where performance starts to sag, and set your threshold at about 70% of that point.
**Step 4 - Wait for the loading overlay to disappear**
Before every click, add a “Wait for Element Vanish” step targeting SAP’s busy indicator. Press F12 in your browser during a screen load to find the exact element name for your NetWeaver version - it’s usually something like the SAP busy indicator or loading overlay div.
Set the timeout to about 45 seconds and turn on Continue On Error, because the overlay being already gone is a perfectly valid state and shouldn’t throw.
This single step eliminates the invisible-layer click interception.
**Step 5 - Change WaitForReady to COMPLETE**
Check every UI activity in your process. Many default to “INTERACTIVE,” which finishes as soon as the page structure is parsed. For a screen like SAP’s, that means almost nothing is actually usable yet.
Change all of them to “COMPLETE” so the activity waits for the page to genuinely settle before acting.
**Step 6 - Switch input mode to Simulate**
Change your clicks and type-into activities from Hardware Events to Simulate. Simulate sends the action directly to the page element instead of physically moving the mouse. It bypasses the invisible overlay entirely, runs in the background, and is roughly three times faster.
If a particular SAP control doesn’t respond to Simulate, try Chromium API for that one control before falling back to Hardware Events.
-–
**Step 7 - Build one reusable “screen ready” workflow**
Create a single workflow that you invoke everywhere a screen changes. It should do three things in order:
1. Wait for the SAP busy indicator to vanish
2. Check App State on the screen’s anchor element with WaitForReady set to COMPLETE, and throw a clear timeout error if it never appears
3. Verify the element is actually enabled, not just present - an element can exist while still greyed out
Pass in the anchor element and timeout as arguments so you can reuse it across every screen in your process.
**Step 8 - Delete every Delay activity**
Search your project files for Delay activities and remove them all. The only two acceptable exceptions are a deliberate throttle to protect a downstream system, and a cooldown pause in your circuit breaker. Both should have a comment explaining why they exist.
Every other Delay is a defect waiting for a proper wait condition.
**Step 9 - Fix your selectors**
If any selector contains a generated SAP ID something like M0:46::0:33 - it will break the next time the screen redraws or the next time a transport goes in.
Move those targets into Object Repository and rebuild them using stable attributes like aria-label, control type, or title. Add anchors for any field that’s ambiguous, using its label as the anchor point.
**Step 10 - Release SAP locks on every failure**
When a queue item fails partway through a transaction, SAP holds a lock on that object. The next item touching the same object waits for the lock to time out, which looks exactly like “SAP is slow.”
In every exception handler, cancel the current transaction with F12, then send “/n” to return home and release the lock. After a test run with deliberate failures, check SM12 - it should be empty.
**Step 11 - Verify outcomes, not clicks**
A click that technically succeeded isn’t a business success. Wrap every Save, Post, and Enter in a Verify Execution step that checks for the actual result - the success message in the status bar, or the document number appearing.
This turns silent failures into explicit errors your retry logic can actually respond to.
**Step 12 - Use exactly one retry layer**
Use one Retry Scope per logical unit of work, with three attempts and increasing wait times between them. Do not nest Retry Scopes. Three nested layers means 27 attempts, which can hang your process for several minutes while holding a SAP lock.
Also, classify your errors before retrying. Business errors like “vendor blocked” or “not authorized” should fail immediately with no retry. Only technical errors like timeouts and session drops deserve a retry.
**Step 13 - Add a circuit breaker**
If three transactions fail in a row, stop consuming the queue. Recycle the browser, wait five minutes, then try a single test item. If it works, resume normally. If it fails, wait longer and raise an alert.
Without this, a SAP outage at 2am will burn through your entire queue into a Failed state before anyone notices.
**Step 14 - Lock down the browser environment**
Give each robot its own dedicated browser profile that gets deleted and rebuilt at every recycle. Turn off hardware acceleration since the robot VM has no real graphics card. Remove every browser extension except the UiPath one - others inject scripts into the SAP page and slow down element detection. Disable Chrome auto-updates through policy and pin the version, since silent updates are a leading cause of overnight failures. Lock screen resolution at 1920x1080 with 100% scaling.
**Step 15 - Add structured logging**
Log these values for every transaction: queue item reference, SAP transaction code, total duration, screen load time, retry count, browser memory, and how many transactions since the last recycle.
Once you have this, you can see degradation coming instead of discovering it when the process fails.
**Priority order**
If you can only do a few things this week, do them in this order:
**First** - Wait for Element Vanish on the busy indicator, plus switch to Simulate mode. This fixes the click failures immediately.
**Second** - WaitForReady set to COMPLETE everywhere.
**Third** - Counter-based browser recycle replacing per-item logout. This flattens the degradation completely.
Those three changes typically recover about 80% of the total improvement.
**What to expect**
Memory stays flat across the whole run instead of climbing. Success rate moves from roughly 90% up to 99% or better. Each item runs 45–60% faster, because you stop sleeping through screens that already loaded in under a second. The robot runs unattended overnight instead of needing a restart every 150 items.
The counterintuitive part worth remembering: the fix for “it gets slower over time” is to restart the browser *less* often but *properly*, and the fix for “clicks fail” is to wait for a *condition* rather than a *duration*.