USR04 table — USR04 user profile assignment runtime table
USR04 holds, per user and client, the list of authorization profiles the kernel actually loads into that user's authorization buffer at logon, together with a validity period. It is the runtime record behind SU01/PFCG role assignment, not the role assignment itself, and it only reflects a role change after a user master comparison has run.
USR04 is the legacy, kernel-level table that carries a user's assigned authorization profiles and their validity dates, and it is what actually gets read when a user logs on. The page covers why this table frequently disagrees with what PFCG shows as assigned, and how to prove that disagreement in data rather than guessing at it.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 971 words
What it stores
One row of USR04 represents, for a given user in a given client, the current set of authorization profiles that user carries plus a single validity window for that assignment. Historically this was maintained directly through SU01 profile assignment before PFCG existed; today it is maintained indirectly, populated when a PFCG role generates a profile and that profile is compared into the user master. The table is deliberately not normalized to one row per profile: the profile list is packed into an internal field rather than exposed as separate rows, because it was designed to be read once at logon by the kernel, not queried by reporting tools. It is the actual source the authorization check reads from, which makes it the ground truth for what a user can do right now, independent of what PFCG or the role assignment tables say should be true.
Key fields
- MANDT - client, always restrict on this first
- BNAME - user name, the join key to every other user table
- GLTGV - validity start date of the profile assignment
- GLTGB - validity end date of the profile assignment
- PROFS - internal field carrying the packed list of assigned profile names, not directly filterable by a single profile name in a WHERE clause
How it joins the data model
- USR04-BNAME = USR02-BNAME to bring in lock status, password state and last logon alongside the profile assignment
- USR04-BNAME = UST04-BNAME to get the same profile assignment normalized into one row per user and profile, which is the version worth querying directly
- USR04-BNAME = AGR_USERS-UNAME to compare the target role assignment coming from PFCG against what has actually landed in the runtime table
- USR04-MANDT = USR02-MANDT, always join on client to avoid cross-client noise on shared systems
How to read it safely
Always restrict by MANDT first, this is a multi-client table on any system that runs more than one client. BNAME is the natural second filter and gives excellent selectivity, so a lookup on a single user is cheap even on a large user base. Do not attempt to filter on PROFS directly, it is an internal packed field and a WHERE condition against a profile name will not behave as expected; use UST04 instead when the question is which users hold a specific profile. Also check GLTGV and GLTGB together, a profile can be present in the table but outside its validity window and therefore not effective.
How to prove it in the data
Symptom: a user reports losing access to a transaction the day after being added to a role. Query UST04 for BNAME equal to that user and check whether the expected profile is present and whether its GLTGV/GLTGB window covers today. If the profile is missing entirely from UST04 while AGR_USERS shows the role assigned, the user master comparison has not run for that user, which is the actual root cause, not a role design defect.
ECC vs S/4HANA
USR04 still exists on S/4HANA and still plays the same role as the kernel-level source for the authorization buffer at logon. The PFCG-based role and generated-profile mechanism is unchanged, so the same comparison-lag behavior applies. There is no known CDS compatibility view replacing it for reporting purposes; the normalized UST04 remains the practical read path when a query needs to filter by profile rather than by user.
Common pitfalls
- Seeing a role in AGR_USERS and assuming the user already has the corresponding access; the effective access lives in USR04/UST04 and only appears there after a user master comparison, so a fresh role assignment can look correct in PFCG and still fail at runtime for a period of time
- Reflexively removing and re-adding the role when access appears missing; this does not force the comparison and just adds noise to the assignment history without fixing the underlying lag
- Trying to filter USR04 directly on a profile name; PROFS is a packed internal field, not a simple string column, and a naive WHERE clause against it returns nothing usable
- Assuming a locked user or a reset password shown in USR02 has any bearing on the profile list in USR04; the two concerns are independent and get confused during incident triage
- Treating a role revocation in AGR_USERS as an immediate access cutoff; the profile can remain live in USR04 until the next comparison runs, which matters during offboarding and emergency access revocation and is worth checking explicitly rather than assuming
- Ignoring GLTGV/GLTGB and assuming role assignment validity dates in PFCG and profile assignment validity dates in USR04 are always identical; manual profile handling or migration artifacts can leave them out of sync
Whose problem this is
This is security or IAM administration territory, specifically whoever owns SU01/PFCG operations and the scheduled user master comparison job. Application or functional teams reporting an access problem should hand the diagnosis to security rather than attempt to interpret USR04 or UST04 themselves.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/usr04ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.