S_GUI — S_GUI Authorization for Front-End GUI Activities
S_GUI controls whether a user can perform client-side (front-end) operations from within SAP GUI, most commonly downloading data to a local file or uploading a file into the system. It is checked inside shared function modules such as those behind ALV export, list download, and SE16 data export, independent of which transaction called them, which is why a fully authorized transaction can still fail at the download button.
This page covers what S_GUI restricts, the single activity field it checks, and the transactions and reports that trigger it during a download or upload operation. The focus is on tracing a failed check, since S_GUI failures occur deep inside a function module rather than at transaction start, which routinely misleads consultants into checking the wrong authorization object.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 821 words
What it protects
S_GUI guards operations that move data between the SAP application server and the user's local workstation through SAP GUI, principally downloading a list or table to a local file and uploading a local file into the system. It also covers other GUI-side actions triggered from standard front-end function modules, such as certain print and clipboard operations invoked from list processing. The structural fact that explains most confusion is that this object is not checked when a transaction starts, it is checked inside the shared function modules that actually perform the front-end operation. That means the same S_GUI check fires from ALV grid export, SE16 data export, SQ01 query download, and any custom report built on the standard download function modules. A user can hold full authorization for a transaction and still be stopped the moment they click 'export to local file', because the check sits after the transaction's own authorization checks have already passed.
Fields checked
- ACTVT - restricts which direction of file transfer is permitted, principally download or export of data from the system to the front end versus upload or import of a file from the front end into the system. A user granted the download value is not automatically granted upload, and the two need to be assigned separately if both are required.
Where it is checked
- ALV grid toolbar 'export' or 'local file' function, checked at the moment the file write is attempted, not when the report is run
- Classic list processing via System, List, Save, Local file, checked inside the underlying download function module
- SE16 and SE16N data browser export to spreadsheet or local file
- SQ01 and SQVI query result download
- Custom Z reports and interfaces built on standard download or upload function modules that call the S_GUI check before writing to or reading from the front end
- File upload dialogs invoked from custom transactions that read a local file into an internal table
How to trace a failed check
Reproduce the failure and pull SU53 immediately afterward, since S_GUI checks happen inside shared function modules and the buffered result can be overwritten quickly by subsequent checks in the same session. SU53 will normally show S_GUI with the ACTVT value that was requested, download or upload. If SU53 shows nothing useful, or shows an unrelated object because something else was checked afterward, switch to the authorization trace transaction and reproduce the exact click that fails, then filter the trace to S_GUI. Capture the user id, the exact action attempted (download versus upload), the transaction or report from which it was triggered, and the timestamp, and hand that package to security rather than a screenshot of a generic error message. Do not ask for S_GUI with all activity values as a blanket fix; identify whether the business need is download, upload, or both, since granting both when only one is needed is exactly the kind of broad grant that data protection reviews flag later.
Whose problem this is
Ownership sits with the security team, since S_GUI grants are almost always reviewed for data exfiltration risk before being added to a role. Functional consultants should determine whether the failing action is a download or an upload, name the transaction or report where it occurs, and state the business justification, since security teams are often reluctant to grant download broadly without one.
Common pitfalls
- Role contains S_GUI with the download value but the user still cannot download, because they actually triggered an upload path, or vice versa; the two activity values are not interchangeable
- A failed S_GUI check gets misread as a missing authorization for the transaction itself, prompting a broad transaction-level role change that does not fix anything because the transaction start check already passed
- SU53 shows an unrelated failed check because something else in the same screen was evaluated after the S_GUI failure, sending the investigation in the wrong direction
- Security teams frequently restrict S_GUI deliberately as a data loss prevention control, so a 'correct' role built purely from a functional checklist can still be denied on policy grounds, not a configuration error
- Custom reports that call download function modules inconsistently across the codebase can behave differently for the same user depending on which report they run, making the issue look intermittent when it is actually a coding inconsistency
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-guiERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.