AGR_DEFINE table — AGR_DEFINE role header table

AGR_DEFINE holds the base master record for a PFCG role, which SAP internally still calls an activity group, hence the AGR prefix used across this whole family of tables. Each row corresponds to exactly one role name and carries the administrative facts about that role: when it was created and last changed, and by whom, plus its category, meaning whether it is a single role, a composite role that bundles other roles, or a derived role that inherits menu and authorization structure from a parent role. It does not hold the menu, the authorization objects, or the list of assigned users. Those are held in separate tables keyed on the same role name. A missing row here for a role name that shows up elsewhere in the AGR_* tables usually means the role was deleted, renamed, or never transported correctly.

Always restrict by MANDT first, this is a client-dependent table and cross-client selection returns meaningless duplicates across landscapes replicated in the same system. AGR_NAME is the natural filter; use the customer naming convention prefix (commonly Z or Y for custom roles) to scope a selection before joining outward. The table itself is small relative to AGR_1251 or AGR_USERS, since it holds one row per role rather than one row per authorization field or per user assignment, so it is rarely the performance bottleneck. The bottleneck sits in whatever table gets joined to it next.

To confirm a role genuinely exists and to check its type before chasing an authorization complaint, select AGR_DEFINE with MANDT equal to the working client and AGR_NAME equal to the role in question. If the row is missing, the role name quoted by the user or found in AGR_USERS is stale, misspelled, or was deleted after assignment; stop investigating authorization content and go fix the assignment or transport gap first.

AGR_DEFINE continues to exist as a standard table in S/4HANA and PFCG remains the transaction that maintains it; no compatibility view replacement is required because the underlying role concept did not change shape. Business roles and Fiori catalog assignments built for Fiori launchpad access sit on top of this same PFCG role model rather than replacing it, so authorization troubleshooting for Fiori-based access still traces back through AGR_DEFINE and its sibling tables.

Role master data questions belong to the security or identity access management team that owns role design and PFCG maintenance. GRC access risk analysis teams query this table indirectly through their tools when scoping risk analysis to specific roles. Basis is only involved if the table itself needs technical repair, which is rare.

PFCG writes and maintains AGR_DEFINE directly whenever a role is created, changed, or deleted. AGR_USERS records the user-to-role assignment and validity dates. AGR_1251 holds the authorization object values maintained in the role. AGR_TCODES holds the transaction codes assigned in the role menu. SU01 and mass user maintenance transactions read AGR_USERS rather than writing AGR_DEFINE directly.