SUIM — User Information System report tree
SUIM is the entry point to a report tree, not a single report or table. It groups dozens of standard reports covering users, roles, profiles, authorizations, transactions, and change documents. Each sub-report queries different tables with different logic, so picking the wrong report by name alone is the most common cause of a wrong answer during an access review or audit.
This page covers SUIM as the User Information System launcher, how to pick the right sub-report for a given access question, and the underlying tables that back the most-used reports. It focuses on the failure modes that produce false positives or false negatives during audit and incident work - expired assignments, composite role blindness, buffer lag, and runtime scope the reports cannot see.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,215 words
Purpose
SUIM is the entry transaction for the SAP User Information System, a report tree, not a single report or table. It groups dozens of standard reports, technically separate programs, covering users, roles, profiles, authorization objects, transactions, and change documents. Selecting SUIM does not run anything by itself; it opens a folder structure and the consultant has to pick the specific report matching the question being asked - who has this authorization value, which roles contain this transaction, which users changed since a given date. The structural fact behind most confusion: each sub-report queries different tables with different join logic and different performance profiles, so two reports that sound similar, such as 'users by authorization value' versus 'users by complex selection criteria', can return different populations for what looks like the same question.
When it is used
Reached for whenever someone needs an access answer without opening every role individually: audit requests such as listing everyone who can post to a company code, incident response such as who had display access to a customer master before a leak, pre-go-live segregation of duties checks, cleanup before a role redesign, or verifying that a PFCG change actually removed access from every affected user. Used instead of PFCG when the question spans many users or many roles at once rather than the content of one role. On S/4HANA, GRC Access Control or a dedicated access review app may handle scheduled, governed reviews, but SUIM remains the fastest ad hoc tool when someone asks a one-off question mid-call and there is no time to build a formal query.
How to use it in practice
- Call SUIM and expand the relevant branch: Users, Roles, Profiles, Authorizations, Transactions, or Change Documents.
- Pick the report that matches the question, not just the closest-sounding one - 'user by complex selection criteria' filters on master data attributes, 'user by authorization values' filters on actual authorization content, these are not interchangeable.
- Enter selection criteria narrowly first, one object and one value, to gauge result volume before widening the search.
- Decide explicitly whether to include users or roles with expired validity - this checkbox changes the returned population significantly and is easy to miss.
- Execute, then use the output as a worklist to drill into PFCG or SU01 for the specific object that needs correction.
Key data objects
- USR02 - user master logon data, one row per user, the anchor table for most user-based reports
- AGR_USERS - assignment of roles to users including validity dates, the join point between role reports and user reports
- AGR_1251 - authorization field values stored against each role, what most who-has-access-to-X reports actually scan
- AGR_TCODES - transactions assigned to each role, used by transaction-based SUIM reports
- USH02 - change history of the user master, source for the change-documents-for-users report
How to prove it in the data
To confirm who really has a given authorization value without trusting the SUIM output at face value, go to SE16 on AGR_1251, filter on the object and field or value in question, and take the resulting role names. Then check AGR_USERS for those role names, filtering so today's date falls inside the validity window on those rows. Cross the surviving user list against USR02 to exclude locked or expired accounts. Any user SUIM listed that this join drops has an expired assignment; any user missing from SUIM but present in the join usually means the report ran with the exclude-expired option set.
ECC vs S/4HANA
SUIM itself is unchanged on S/4HANA; the report tree and the underlying programs run the same way as on ECC. What has moved is the governance layer around it - GRC Access Control and periodic access review apps increasingly handle scheduled, auditable reviews, leaving SUIM as the ad hoc, unscheduled tool for one-off questions during an incident or a call. No SUIM report has been retired or replaced one-to-one by a Fiori app.
Common pitfalls and how to diagnose them
- Expired assignment mismatch - the report offers a checkbox for validity period; leaving it at default hides users whose role assignment expired but who still appear in PFCG's user list for that role. Always check the validity dates in AGR_USERS before concluding a user still has or never had access.
- Composite role blindness - authorization content lives in single roles, not in the composite role that groups them. Running an authorization-value report against a composite role name returns nothing; the report has to point at the single roles inside it, or run without a role filter and be cross-referenced afterward.
- Buffer lag - a role change saved and even transported does not immediately change what a logged-on user can do; the runtime buffer only refreshes at next logon or explicit reset. SUIM reflects stored role content, not the live buffer, so a user who still appears to have access minutes after a fix may simply not have logged off yet.
- Runtime scope not shown - static authorization value reports do not account for organizational-level restrictions resolved at runtime, structural authorization, or custom checks in code. A user can appear to hold an object and value combination in SUIM and still be blocked at runtime by a layer SUIM cannot see.
- Report choice mismatch - reports with similar names filter on different criteria: master data attributes, actual authorization content, or assigned profiles. Picking the wrong one and treating an empty result as proof of no access is the most common false negative during an audit response.
- Performance on wide selections - authorization-value reports without a narrow object or field filter scan across every role and profile in the system. On a large system this looks like a hang rather than a slow query, and restarting the session loses the selection screen and wastes another cycle.
Whose problem this is
Security or GRC functional territory almost always; SUIM is a diagnostic tool that team uses to answer its own questions, not something ABAP or Basis normally need to touch. ABAP gets involved only if a custom authorization object or custom report is added to the tree. A good handover includes the exact report name used, the selection criteria entered, and raw table evidence from AGR_1251 and AGR_USERS, not just a screenshot of the SUIM list.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/suimERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.