A short reference, sourced from Microsoft Learn
The eight limits Power Automate Desktop hits on SAP GUI
If you landed here from a thread asking why a PAD SAP flow keeps failing, this is the short list. Eight caps, each one with the Microsoft Learn page that documents it, in the order you usually hit them.
Direct answer, verified 2026-05-20
Power Automate Desktop's SAP automation actions sit on top of the SAP GUI Scripting COM interface, and they inherit eight concrete limits from Microsoft and from SAP itself: (1) six concurrent sessions per SID, (2) no GuiTree capture in SAP actions, (3) SAP GUI 750 or later required, (4) sapgui/user_scripting must be set to TRUE on the application server, (5) S_SCR authorization on every running user, (6) accessibility mode and scripting enabled in SAP GUI Options on the operator machine, (7) element IDs that bind to the SAP scripting tree and rearrange on support packs, (8) synchronous scripting that is sensitive to background load and Windows modal dialogs. Sources for each are Microsoft Learn: SAP actions reference, scripting configuration, prerequisites guide, and the GuiTree workaround.
The eight limits, one by one
Each entry quotes or paraphrases the Microsoft Learn page that documents it. If something here looks wrong against your install, open the source link in the byline below the entry; the docs are the canonical record, this page is a digest.
Six concurrent sessions per system, hard cap
The Launch SAP and Create new SAP session actions both note that SAP GUI does not allow more than six active connections (sessions) to an SAP system. PAD inherits the SAP-side limit because each session it spins up counts against the same ceiling. If your queue needs more than six parallel runs against one SID, PAD on this surface cannot deliver it; you either fan out across multiple SAP systems, multiple Windows hosts behind one user, or you run sequentially and lose the throughput.
GuiTree objects cannot be captured
Microsoft's own support article on this is blunt: 'Power Automate for desktop doesn't capture SAP GuiTree objects when you use SAP automation actions.' Tree controls show up across SAP GUI in places like the SE16N data browser, organizational structure transactions, and report selection screens. The workarounds Microsoft documents are either falling back to UI automation actions (driving the same window via Windows UI Automation) or falling back to SAP GUI scripting (writing VBScript). In other words, the dedicated SAP action set quietly drops you back into the generic UIA action set for one of the most common SAP controls.
SAP GUI 750 or later, no older clients
The action reference explicitly carries the note 'Power Automate for desktop supports automation with SAP GUI version 750 or later.' That puts a hard floor under any deployment that still runs an older SAP GUI for Windows on the operator desktops. In practice most large estates have rolled forward, but it bites the long tail: factory-floor laptops, locked-down lab images, kiosks built for an older S/4 rollout, and acquired subsidiaries on their own patch cadence.
sapgui/user_scripting=TRUE, set by Basis, signed off by security
The PAD prerequisites guide walks you through opening transaction RZ11, finding sapgui/user_scripting, and flipping it to TRUE; making it permanent through RZ10 if you do not want the change to evaporate at the next application-server restart. That is a change on the SAP application server, not on the operator's Windows box. In a regulated environment it is also not a checkbox: most security teams treat enabling user scripting as a privilege-escalation surface, because any logged-in user with a desktop session can now drive the GUI from a script. Expect a security review, a change ticket, and in some shops an explicit board sign-off before this gets enabled.
S_SCR authorization on every running user
Enabling the parameter is not enough. Every SAP user that PAD logs in as needs the S_SCR authorization object granted in their role, or the scripting actions fail. In a real deployment that means a role change tracked through your normal SAP role-management process, with the usual SoD review attached. If you are running PAD as a dedicated service account, that account also needs the role.
Two client-side toggles, on every operator's machine
On the machine that actually runs the flow, SAP GUI Options has to be opened, accessibility mode has to be enabled under Accessibility and Scripting > Accessibility, and scripting has to be enabled under Accessibility and Scripting > Scripting. If the operator desktop image is locked down (it usually is), those toggles need to be pushed through Group Policy or a managed install profile. New laptop, new image, no toggle, no run.
Element IDs bound to SAP's screen tree, brittle on support packs
PAD's Click SAP UI element, Populate SAP text field, and Get details of SAP UI element actions all take an SAP element ID as input. That ID is the SAP scripting tree's positional address, the same one VBScript would use, of the form usr/subSCR/.../txtFIELD. When a SAP support pack rearranges a screen, hides a sub-screen behind a new container, or a customer-specific transaction wraps the standard one, the address moves. The bot that recorded the old path now resolves to a different node, or to nothing. The recording session was binding to the build, not to the field.
Synchronous scripting, sensitive to timing and Windows dialogs
SAP GUI scripting is synchronous and UI-driven. Microsoft's troubleshooting docs note that poor timing or heavy background activity on the operator machine can cause scripts to lag or freeze the SAP session, and that Windows dialog windows that appear during some operations may not be interactable with SAP GUI scripts, so the run hangs waiting for a click that the script cannot deliver. In practice that means flaky weekend runs on shared VMs and queues that stall when SAP throws a Windows-level confirmation dialog at the user.
“SAP GUI doesn't allow more than six active connections (sessions) to an SAP system.”
Microsoft Learn, SAP GUI automation actions reference for Power Automate for desktop
What this looks like, side by side
The same step on the same SAP screen (transaction FB01, fill the Company Code field). On the left is what PAD records when it uses the SAP scripting tree; on the right is what Mediar writes when it binds to the Windows UI Automation tree.
Power Automate Desktop, SAP actions
Mediar, accessibility-tree selector
The PAD step works the day you record it. It breaks the day SAP rearranges the screen sub-container holding BUKRS, because wnd[0]/usr/ctxtBKPF-BUKRS is the address, not the field. The Mediar step keeps working because name:Company Code|role:Edit is the field, regardless of where the sub-container lives.
What changes when you swap the input layer
Both tools end up driving the same saplogon.exe window on the same operator host. The difference is which surface they read on the way in. PAD's SAP actions go through SAP's COM scripting interface, so they pick up SAP's prerequisites. Mediar's selectors go through the Windows UI Automation tree, which already exists for accessibility tools.
Two paths to the same SAP window
The PAD path needs the SAP application server to have sapgui/user_scripting set to TRUE, the running user to have S_SCR, and the operator's SAP GUI to be 750+ with accessibility and scripting toggled on. The Mediar path needs an accessibility tree, which Windows publishes for every native window by default.
If you are stuck on one of these limits today
If it is the six-session cap. That is SAP, not PAD, and no UI automation tool will get around it. The honest options are batching workloads sequentially against one SID, partitioning across multiple SIDs (dev, qa, prd-shadow), or asking your Basis team about background-job routes (BAPI, RFC, IDoc) for the high-volume slice and keeping UI automation only for the screens that have no programmatic surface.
If it is the GuiTree gap or the screen-ID brittleness. Both go away the moment you stop binding to the SAP scripting tree. Either fall back to PAD's generic UI automation actions against saplogon.exe (Microsoft suggests this themselves), or use a tool whose primary selector is the OS accessibility tree, where tree nodes have names, roles, and parent windows that survive a support pack.
If it is the Basis enablement and the per-user S_SCR. That review is going to happen however many times you bring up scripting-based automation. The way to skip it is to not be on the scripting interface in the first place. Accessibility-API agents read the same window without asking SAP to expose its scripting surface.
If it is the synchronous-scripting flakiness. That one is harder to engineer around without rewriting the integration. A runtime that classifies stalls into infrastructure vs workflow-logic vs unknown, and re-resolves elements on every run instead of caching the scripting-tree address, handles most of the symptoms; the underlying race conditions on the operator box do not. If the SAP screen is genuinely paint-blocked because of a Windows modal dialog the script cannot click, you need a tool that can see a new top-level window appear and route to a fallback.
Walk one of these PAD SAP flows with us and we will tell you the honest path
Show us a flow that keeps breaking, or a Basis review you cannot get through, and we will say whether an accessibility-tree agent solves it or not. No pitch deck.
Frequently asked
Is Power Automate Desktop missing an SAP GUI feature, or is it just SAP being SAP?
Both, and the line is worth knowing. The six-session cap, the S_SCR authorization, and the sapgui/user_scripting parameter are SAP-side rules that any tool driving the COM scripting interface inherits, including VBScript, UiPath, Automation Anywhere, and Blue Prism, not just PAD. The GuiTree capture gap and the SAP GUI 750+ floor are Microsoft-side: Microsoft's own docs say PAD does not capture GuiTree objects and supports SAP GUI 750 or later. The fragility on support packs is a property of any selector that addresses SAP's screen scripting tree by ID.
Can we just use PAD's generic UI automation actions and skip the SAP scripting layer?
You can, and Microsoft suggests exactly that as a workaround for the GuiTree gap. That path drives the same saplogon.exe window through Windows UI Automation, which sidesteps S_SCR and the sapgui/user_scripting parameter. The catch is that PAD's UIA actions on SAP windows are a generic Windows control surface; you lose the SAP-typed exception messages, the element-type metadata, and the ergonomics the dedicated SAP actions give you. You are using PAD as a generic Windows automation tool at that point, not as a SAP RPA tool.
Does enabling sapgui/user_scripting really matter for security?
Most SAP security teams treat it as a privilege-escalation surface. Once the parameter is TRUE and a user has S_SCR, anything that can run on that user's Windows desktop, including a script the user did not write, can drive the SAP GUI as that user. That is fine for a locked-down automation host running one signed flow. It is not fine to flip on globally in a shop where SAP front-end PCs run user-installed software. The right scope is per-application-server and per-user, gated by role.
What breaks when SAP ships a support pack against a PAD recording?
PAD's SAP actions store the SAP element ID, which is the position of the field in SAP's scripting tree (something like wnd[0]/usr/subSCR1234/ctxtBKPF-BUKRS). Support packs are allowed to rearrange that tree. When they do, the recorded ID either resolves to a different node (you populate the wrong field) or resolves to nothing (the step throws Populate Sap Text Field Value error). The fix is to recapture every affected step. A selector that addresses the same field by accessibility name and role survives the rearrangement because it describes what a person reading the screen sees, not the build's internal layout.
Does any of this apply to S/4HANA Fiori or Web GUI?
No. The PAD SAP actions in scope here are the SAP GUI for Windows actions, which talk to the COM scripting interface on saplogon.exe. Fiori is a Chromium app; it exposes its DOM and the Chrome accessibility tree to PAD's browser automation actions. SAP GUI for HTML / Web GUI is also browser-driven. The eight limits in this catalog apply to the classic Windows GUI surface, which is still the bulk of ECC and a meaningful slice of S/4 deployments that have not migrated off the desktop client.
How is Mediar's approach different on this specific surface?
Mediar drives the same saplogon.exe window, but it resolves fields through the Windows UI Automation tree on the operator host using accessibility name plus role plus process name selectors (for example, name:Company Code|role:Edit, process_name:saplogon.exe). That path does not require sapgui/user_scripting on the SAP server, does not require S_SCR on the user, does not need SAP GUI 750 specifically (it works on whatever GUI version the operator has), and is not bound to the scripting tree's element IDs, which is why it survives support packs without re-recording. GuiTree controls expose accessibility nodes, so they are reachable too. The trade is honest: you give up the SAP-typed action ergonomics, and in exchange you get a path that does not depend on the Basis team enabling scripting, and that does not break the day SAP repaints a sub-screen.
Other entries from the same shelf
Adjacent reading
How to automate SAP, branch by branch
BAPI, SAP GUI Scripting, RPA, and accessibility-tree agents, with the questions that decide which path is honest for your estate.
Where RPA stalls on legacy desktop apps
The seven recurring failure points that take selector and pixel bots down on SAP, Oracle EBS, and mainframe terminals.
AI agents for legacy desktop systems with no API
Why an accessibility-tree agent works on SAP GUI, Jack Henry, Fiserv, Epic, and Cerner without sapgui/user_scripting or per-vendor adapters.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.