SU21 — Maintain Authorization Objects and Object Classes

SU21 maintains the authorization object catalog: object classes (functional groupings like HR, FI, Basis, or a custom class), the authorization objects within each class, and the field list attached to each object. An object can have up to ten fields, typically an activity field (ACTVT) plus one or more business fields such as company code, document type, or a custom key. The structural fact that causes most confusion is that SU21 only defines shape, not behavior. Nothing checks anything just because an object exists here. A developer still has to code an AUTHORITY-CHECK OBJECT statement referencing the object and its fields, and someone still has to link the object to the relevant transaction or service in SU24 so that PFCG proposes it when a role is built. Skip either step and the object sits in the catalog doing nothing.

SU21 gets used during custom development work, not during day-to-day role administration. It is reached for when a custom transaction, custom RFC-enabled function module, custom BAdI implementation, or a custom Fiori OData service needs a security check that no standard SAP object covers with enough granularity. The typical trigger is a functional requirement like 'restrict this custom report by plant and document type' where no delivered object carries both fields together. It is also used, less often, to extend an SAP-delivered object class with a Y or Z copy when the delivered object is close but not flexible enough and cannot be modified directly. It is not the tool for assigning objects to roles, maintaining default values, or troubleshooting a specific user's missing authorization; those live in PFCG, SU24, and SU53/SU56 respectively.

To confirm whether a custom object actually exists and is transported correctly, run SE16 on TOBJ filtered by the object name and compare the field list on screen against what SU21 shows in the target system; a mismatch between systems usually means an incomplete or stuck transport. To confirm the object is wired into role proposal, check the SU24 check indicator tables (commonly referred to as USOBT_C and USOBX_C for the customer versions) filtered by the transaction code, and confirm the object name appears with a check or check/maintain indicator rather than being absent or set to 'no check'.

SU21 is unchanged on S/4HANA; it remains a transaction-based tool with no Fiori equivalent, and custom authorization object creation still works exactly the same way. What has changed is where objects get consumed: custom Fiori apps built on OData services or custom CDS-based analytics still rely on objects defined in SU21, checked either in the service implementation class or via CDS-based access control, so the object creation step has not disappeared even where the consuming interface is now a Fiori app rather than a classic transaction.

This sits with the security or authorizations consultant in collaboration with the ABAP developer who codes the check; it is a development-adjacent task, not a Basis or role-administration task. A good handover includes the proposed object name and namespace, the exact field list with data element references, the activities required, the program or service that will check it, and the transport request number so the linkage into SU24 and PFCG can follow without guessing.

SU24 is the natural next stop, since an object created in SU21 has no effect on role building until it is linked there against a transaction with a check indicator and proposed values. PFCG is where the consuming role builder eventually sees, or fails to see, the new object as a default. SU56 and a trace via ST01 are the practical tools for proving at runtime whether a specific user is failing a check on the new object, which is often the first symptom that surfaces before anyone traces it back to a missing SU21 or SU24 step. SUIM is useful afterward for reporting which roles or users carry the new object once it is in productive use.