AGR_USERS table — Role to user assignment table

Each row in AGR_USERS is one assignment of one user to one role, with a validity period. When a security admin assigns a role to a user in PFCG, or via mass assignment in SU10, a row is written here for the role name and the user ID, carrying a start date and an end date. The table holds both single roles and composite roles; for a composite role the row represents assignment to the composite object itself, not to the single roles it aggregates. AGR_USERS does not carry authorization values -- it is purely the roster of who is assigned to what, for what period. It is the first table most access review and audit scripts read, because it answers 'who has this role' without touching the generated authorization profile.

The table is narrow: a client, a role name, a user name, and two validity dates. Everything about what the role actually grants lives in other tables, not here.

The consultant path from AGR_USERS almost always runs outward: from role and user, to what the role contains, to what the user's logon looks like.

Always restrict on MANDT plus either AGR_NAME or UNAME before running a query; the table grows to millions of rows in landscapes with high role turnover, and an unrestricted scan on UNAME alone across a large user population is slow. For an 'active access today' question, add FROM_DAT less than or equal to today and TO_DAT greater than or equal to today, since expired rows are not deleted and remain in the table indefinitely until a cleanup job removes them. If the role in question is a composite role, do not stop at AGR_USERS -- the single roles it contains are listed elsewhere and must be expanded to see the real authorization footprint.

To confirm a user currently holds a specific role, select AGR_USERS with UNAME equal to the user ID and AGR_NAME equal to the role name, then check that today's date falls between FROM_DAT and TO_DAT. A row outside that date window confirms the role was assigned but is not currently active. To see everything a user is assigned to right now, select on UNAME alone with the date filter applied, then cross-check each AGR_NAME against AGR_DEFINE to see whether it is single or composite.

AGR_USERS exists in S/4HANA with the same structure and the same purpose it had in ECC. It continues to be written by PFCG when a role is assigned to a user and by mass assignment through SU10. There is no widely used compatibility CDS view replacing it, since it is a security administration table rather than a business transactional table, and reporting against it is still done directly or through the standard role maintenance transactions.

Role assignment is a security or GRC team decision, driven by an access request process, not a Basis task. Basis owns the technical table and the cleanup jobs that remove expired rows. When a business user disputes what access they hold, the security team is the first point of contact, not the functional module team.

AGR_DEFINE holds the role master record that AGR_NAME points to. AGR_1251 holds the generated authorization objects and values for a single role. AGR_TCODES holds the transaction codes assigned to a role's menu. USR02 holds the user master record that UNAME joins to. All of these are written by PFCG when a role is created, changed, or assigned, and by SU10 when assignments are done in bulk.