Maintaining Check Indicators and Default Values in SU24

Explanation

SU24 governs two intertwined things for every transaction code: which authorization objects the authorization concept treats as relevant during runtime checks (the check indicator), and what default field values PFCG proposes when that transaction is added to a menu-based role. Understanding the mechanics is essential before you touch production role builds. When you open SU24 for a transaction, you see a list of authorization objects associated with it, each with a check indicator: Check (the system performs an AUTHORITY-CHECK against this object at runtime and PFCG proposes it), Do Not Check (the check is suppressed system-wide for that transaction-object pair, meaning even users who lack the authorization will pass the check for that object), Check/No Check meaning unmaintained, and Check with Template (the object is checked, and SU24 supplies a default value set as the template, but consultants can still adjust it during role maintenance). The distinction between 'Check' and 'Do Not Check' is not cosmetic - setting an object to Do Not Check effectively disables enforcement of that AUTHORITY-CHECK call for that transaction across all users, regardless of what values exist in their profiles. This is a powerful and risky lever that must be documented and approved through change control, never used casually to silence a trace. Default values are maintained per authorization object per transaction. For example, when maintaining SU24 for a transaction code, a consultant might add authorization object F_BKPF_BUK (or a similar FI object) with a default activity and leave the company code field as unmaintained so it must be filled per role during PFCG maintenance. The design principle is: SU24 defaults should represent the minimally necessary field values that make functional sense for most roles using this transaction, while leaving business-variable fields (org levels like company code, plant, cost center) open for role designers to fill according to job scope. The practical workflow is: a functional consultant or security architect identifies a transaction lacking proper SU24 maintenance (often surfaced via SU53 or STAUTHTRACE findings, or via new custom transactions wrapping standard function modules). They open SU24, add the missing authorization object, set the check indicator appropriately, and populate default values including activity codes and any fixed field values that should never vary (such as an activity that is always '03 Display' for a report transaction). Once saved, the entry becomes part of the USOBX_C/USOBT_C tables (customer tables layered over SAP's SU24 delivery) and will be picked up the next time that transaction is added or that role's authorization data is reconciled via PFCG's 'Update' function (menu-driven comparison of role menu vs. SU24 proposals). A critical operational nuance: changes to SU24 do NOT automatically propagate into existing roles. Only newly created roles, or existing roles undergoing an explicit menu/authorization update (via the reconciliation function in the role's Authorizations tab), will pick up new or changed SU24 defaults. This means a mass SU24 correction project must be paired with a role remediation campaign to actually take effect across the authorization landscape - otherwise the correction sits unused for existing roles. In S/4HANA, SU24 continues to function the same way for classic and derived transaction-based roles, but many Fiori app authorizations are catalog/tile-driven rather than transaction-code-driven, and their default authorization data does not flow through SU24 in the same way; instead, Fiori apps often reference authorization defaults through their own app-to-role assignment metadata and PFCG's business catalog handling. Consultants must not assume SU24 corrections alone will fix Fiori authorization gaps.

Code example

* SU24 is a maintenance transaction, not a programmable object - there is no ABAP* code to 'call' its logic directly, but the pattern it protects is the AUTHORITY-CHECK* statement inside the transaction's underlying program. Example of what SU24 is protecting: AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'  ID 'BUKRS' FIELD BSEG-BUKRS  ID 'ACTVT' FIELD '02'.IF sy-subrc <> 0.  MESSAGE e042(f0) WITH BSEG-BUKRS.ENDIF. * SU24 maintenance for the calling transaction determines:* 1) whether F_BKPF_BUK appears with check indicator 'Check' (enforced) vs 'Do Not Check' (suppressed)* 2) what default ACTVT value (e.g., '02') and BUKRS handling PFCG proposes when this*    transaction is inserted into a role menu * Typical SU24 change control note format used by a security team (not system output):* Transaction: ZFI_INVOICE_POST* Object added: F_BKPF_BUK* Check indicator: Check* Default ACTVT: 01, 02* BUKRS: unmaintained (org-level, to be filled per role)* Justification: custom invoice posting wrapper missing standard FI check propagation

Real project scenario

A security consultant is remediating a custom Z-transaction that wraps a standard FI posting function module. SU53 traces from end users show authorization failures on F_BKPF_BUK that are not being proposed by PFCG when the transaction is added to roles. Investigation in SU24 reveals the custom transaction was never registered with the correct check indicator for that object - it shows as 'Unmaintained'. The consultant adds F_BKPF_BUK with check indicator 'Check', sets a sensible default activity, leaves company code open, documents the change via a transport, and then runs the PFCG authorization update on all roles containing that transaction so the object is proposed and can be filled with the correct org values by role owners.

Common mistakes

• Setting a check indicator to 'Do Not Check' to silence a trace instead of understanding why the check is failing, which globally disables enforcement for that transaction-object pair • Assuming SU24 changes automatically apply to existing roles without running the PFCG authorization update/reconciliation step • Populating default values for organizational-level fields (company code, plant) with a fixed value that does not generalize across all roles using the transaction • Failing to document SU24 changes with business justification, making later audits unable to explain why a check was suppressed or a default set • Confusing SU24 maintenance data with the actual runtime AUTHORITY-CHECK statements in the program, and believing SU24 changes alone can add or remove checks from custom code

Best practices

• Always document the business justification for any check indicator change, especially 'Do Not Check', in a change record referenced by the transport • Leave organizational-level fields unmaintained in SU24 defaults so role designers retain control at the point of role build • Pair every SU24 correction with a plan to run the PFCG authorization update against affected existing roles • Review custom transactions systematically for missing or incorrect SU24 entries before they go live, not reactively after user complaints • Use test users and traces to validate that a SU24 change produces the expected authorization proposal before rolling it to production

Interview angle

Interviewers frequently probe whether a candidate understands that SU24 shapes PFCG proposals rather than performing the runtime check itself, and that 'Do Not Check' is a system-wide suppression with audit implications. Be ready to explain the difference between Check, Do Not Check, and Check with Template, and to describe the reconciliation step required for SU24 changes to reach existing roles.