Maintaining Check Indicators and Role Menu Integration in SU24

Explanation

Configuring SU24 correctly requires understanding the check indicator options and how they interact with the PFCG role menu update process. The main check indicator values are: Check (the AUTHORITY-CHECK is enforced at runtime and the object is proposed into roles that use the transaction), Check/No Maintain (the AUTHORITY-CHECK is still enforced at runtime, but the object is not automatically proposed into new roles, meaning security teams must add it manually if needed), No Check (SAP suppresses the check entirely for that transaction-object combination, which should be used with caution since it can silently widen access), and Do Not Check (organization decision) style options that some releases expose for explicit override. When a security consultant opens a transaction's entry in SU24, they see the list of authorization objects associated with it, the current check indicator, and any default field values maintained for fields within that object (for example a default value for an activity field). The practical workflow for changing SU24 begins with identifying the transaction and object combination that needs adjustment, typically discovered through trace analysis (using authorization trace tools) or through a role build that produced unexpected results. The consultant opens the transaction in SU24, adjusts the check indicator or field default, and saves the change, which should be captured in a transport request for controlled movement through the landscape. Critically, this change does not retroactively affect roles that were already built and generated in PFCG. To propagate the update, the security team must go into each affected role in PFCG, use the role menu update or 'adjust' function that re-reads SU24 data, review the newly proposed values (PFCG will typically flag new or changed objects), and then regenerate the authorization profile. A common intermediate-level task is adding a custom or Z-transaction to SU24 so that it participates properly in the proposal mechanism. Since Z-transactions the organization wrote often lack any SU24 entry initially, PFCG will show no proposed objects for that transaction, forcing security teams to manually add authorization objects to every role that includes it. Registering the Z-transaction's relevant authorization objects and check indicators in SU24 once means every future role that includes that transaction automatically gets the correct proposal, dramatically reducing manual effort and inconsistency across roles. Another integration point is with menu-based role composition: when multiple transactions are added to the same role, PFCG merges and deduplicates the proposed authorization objects, aggregating field values (for example combining multiple activity values as a comma list) into a single object-level entry in the role's authorization tab. Understanding this merge behavior helps explain why a role built from many transactions sometimes shows more permissive combined values than any single transaction technically requires, which is a key least-privilege review point. In S/4HANA, many Fiori app tiles map to OData services and underlying transaction-like authority checks; SU24-style proposal maintenance still applies for the classical transaction codes exposed via Fiori launchpad catalogs, and role design work should treat this the same way, while recognizing that some newer authorization checks for pure Fiori/OData scenarios may not always be fully represented through SU24 and require validation with dedicated Fiori authorization tools.

Code example

* Illustrative workflow only - SU24 is configured interactively, not via ABAP code.* Typical technical steps a security consultant performs:* 1. SU24 -> enter transaction code (e.g., a custom Z-transaction)* 2. Review list of Authorization Objects proposed by SAP or currently empty for a Z-transaction* 3. Set/adjust Check Indicator per object:*      Check              -> enforced + proposed*      Check/No Maintain  -> enforced, not auto-proposed*      No Check           -> not enforced (use cautiously)* 4. Maintain default field values where applicable (e.g., default Activity = 03 Display)* 5. Save and assign to a transport request* 6. In PFCG, open affected role(s) -> Menu tab -> re-run role menu/authorization update* 7. Review 'new' or 'changed' proposals highlighted by PFCG* 8. Adjust org-level and field values as required for the specific role* 9. Generate the authorization profile* 10. Test in QA with a representative test user before promoting to production

Real project scenario

A support team introduced a new Z-transaction for a custom procurement approval workflow. Initially it had no SU24 entry, so every role that included it required security analysts to manually locate and add the correct authorization object and values, leading to at least one role being generated with an overly broad activity value. After a security review flagged the inconsistency, the team registered the Z-transaction properly in SU24 with a Check indicator and a sensible default activity value, then re-ran the role menu update across all six roles that used the transaction, standardizing the authorization footprint and closing the audit finding.

Common mistakes

• Changing a check indicator to No Check to quickly resolve an authorization error instead of investigating the correct field values • Forgetting to re-run the PFCG role menu/authorization update after an SU24 change, leaving existing roles unaffected by the fix • Not registering custom Z-transactions in SU24, forcing repeated manual authorization additions across many roles • Overlooking that PFCG merges and deduplicates values from multiple transactions in the same role, potentially widening combined access beyond what any single transaction needs • Assuming Fiori app authorization behavior is fully captured by classical SU24 transaction-object mappings without separate validation

Best practices

• Use trace-based evidence rather than guesswork before changing any check indicator • Always route SU24 changes through transport requests with documented justification • After any SU24 change, identify and update all affected PFCG roles via the menu/authorization update function, not just the one role that triggered the change • Register every custom Z-transaction in SU24 as part of its development lifecycle, not as an afterthought during role building • Periodically review roles that aggregate many transactions for unintended widening caused by PFCG's value merge behavior • Validate Fiori-specific authorization behavior separately rather than assuming full SU24 coverage

Interview angle

Interview questions at this level often probe the practical mechanics: what happens when you change an SU24 check indicator, does it affect existing roles automatically, and how do you propagate the change. Candidates should be able to walk through the transport-based change process, the PFCG role menu update/adjust step, and explain the risk of using No Check as a shortcut. A strong answer also covers registering custom transactions in SU24 and the implications of PFCG's merge behavior when multiple transactions share a role.