Authorization Object Structure: Fields, Values, and the Activity Concept

Explanation

Once a consultant understands that authorization objects are templates, the next essential skill is reading and configuring their internal structure. Every authorization object is composed of one or more fields, and each field can hold a single value, a set of discrete values, or a range of values. Fields are the actual variables the system compares against user input at runtime; for example a field might represent a company code, a document type, a plant, or a personnel area. Some fields are marked as organizational level fields, meaning they are commonly used to scope access by business unit and are handled specially in role maintenance to support enterprise-wide value derivation across many roles at once. Most authorization objects that control transactional access include an activity field. This field uses standardized two-digit activity values, such as create, change, display, and delete, allowing the same object to control several different operations against the same business object depending on which activities are authorized. This is one of the most important concepts for least-privilege design: granting display-only access to a business process is achieved not by omitting a transaction code, but by restricting the activity field within the relevant authorization object to only the display value, while still allowing the object's other fields to reflect the necessary organizational scope. When a role is built in the role maintenance transaction, the system automatically proposes the authorization objects relevant to the transactions and menu entries added to that role, based on maintained relationships between transactions and objects. The role designer then fills in field values for each proposed object; unfilled fields typically default to a state that either requires later maintenance or, if left fully open, can grant unintended broad access. This is why an incomplete role, one where fields are marked open or unmaintained, is a common source of both access denials during testing and unintended over-authorization if pushed to production without full review. Values within a field can be single, multiple, or expressed as ranges, and many organizations maintain reusable value lists or reference roles to keep field values consistent across similar roles, reducing drift over time. Field values can also intersect with derived roles in a role hierarchy, where a master role defines the transaction and non-organizational field content, and derived roles inherit that content while supplying different values only for the organizational level fields, enabling efficient scaling of similar access across multiple business units. Troubleshooting authorization issues at this level requires the consultant to identify not just which object failed, but which specific field and value combination was missing. A trace of the failed check will show the object, the fields it evaluated, and the values the user's authorizations contained versus what was required. Correcting the issue means adding the precise missing value to the correct field in the correct authorization, not broadly expanding unrelated fields or, worse, assigning a much broader role as a workaround. This precision is what separates a defensible, auditable fix from a shortcut that reintroduces risk. In S/4HANA and Fiori scenarios, the same field-and-value model applies, but additional layers, such as authorization checks tied to OData services and Fiori catalog/tile assignments, mean that a business process may depend on authorization objects being satisfied alongside a properly configured front-end authorization, so a consultant must check both layers rather than assuming a classic backend fix alone resolves a Fiori app access problem.

Code example

* Example of an explicit authorization check inside custom ABAP* This illustrates how a developer checks an authorization object* with specific field values before allowing a custom operation. AUTHORITY-CHECK OBJECT 'Z_MATDOC'  ID 'ACTVT' FIELD '02'      " 02 = Change  ID 'WERKS' FIELD lv_plant. " restrict by plant value IF sy-subrc <> 0.  MESSAGE 'You are not authorized to change material documents for this plant.' TYPE 'E'.ENDIF. * sy-subrc = 0 means all checked fields matched an authorization* the user holds; any other value means the check failed and* the specific missing field/value combination must be traced.

Real project scenario

A consultant supporting a manufacturing client received a ticket where a plant supervisor could display but not release production orders in a specific plant, despite having the correct transaction assigned. Tracing the failed authorization check revealed the activity field for the relevant object was restricted to display only in the assigned role, while the release activity value was missing. Rather than assigning a broader role, the consultant added only the required activity value to the existing authorization within that object, preserving the least-privilege design while resolving the ticket with an auditable, minimal change.

Common mistakes

• Leaving authorization fields unmaintained or fully open in a role, assuming it will be corrected later, which often ships to production unnoticed. • Expanding an entire field's values broadly to resolve an access issue instead of adding only the specific missing value identified through tracing. • Confusing the activity field's role, and granting all activities by default instead of scoping each activity to genuine business need. • Overlooking that Fiori or S/4HANA scenarios may require both backend authorization object satisfaction and correct front-end catalog or service assignment, leading to incomplete fixes.

Best practices

• Always resolve access issues by identifying the specific object, field, and missing value rather than assigning broader roles as a workaround. • Use activity field restrictions deliberately to separate display, change, and other sensitive activities across different roles where appropriate. • Maintain organizational level fields consistently across derived roles to avoid inconsistent scoping across business units. • In S/4HANA and Fiori environments, validate both the backend authorization object result and the front-end catalog/tile or service authorization before concluding a fix is complete.

Interview angle

A common intermediate-level interview probe is to ask a candidate to describe how they would troubleshoot a user's access denial down to the exact missing authorization. Strong candidates describe reading the failed object and field information from a trace or check result, identifying the specific field and value gap, and making a minimal, targeted correction rather than a broad role expansion. Candidates who can also explain the activity field concept and organizational level fields demonstrate genuine hands-on role design experience.