USOBX_C table — USOBX_C: Check Indicators Behind SU24 and PFCG Proposals
USOBX_C stores the customer-level check indicator for every transaction code and authorization object combination, telling SU24 and PFCG whether that object is checked, checked but unmaintained, or deliberately not checked when a role is built. It controls what appears as a proposed authorization object in role maintenance; it does not itself enforce or suppress the actual AUTHORITY-CHECK in the program.
USOBX_C is the check-indicator table behind SU24 authorization defaults and PFCG's automatic object proposals. This page covers what the indicator actually governs, how it joins to USOBT_C and the role tables, and the recurring mistake of treating a no-check indicator here as if it disables authorization enforcement in the code.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,005 words
What it stores
One row in USOBX_C represents a single transaction code and authorization object pair, carrying a check indicator that tells the authorization proposal engine (SU24) and role maintenance (PFCG) how that object should be treated when the transaction is added to a role menu. The indicator distinguishes an object that is actively checked and has maintained field-value proposals, one that is checked but has no maintained proposal (a gap that shows up as an unmaintained yellow or red line in PFCG), and one that is flagged as not relevant so it is excluded from the generated authorization list entirely. This table is the customer-modifiable counterpart to SAP's delivered USOBX table, and it is what governs whether PFCG offers an authorization object as a default when a transaction is inserted into a role, not whether the ABAP program actually performs the check at runtime.
Key fields
- MANDT - client
- TCD - the transaction code the check indicator applies to
- OBJCT - the authorization object linked to that transaction
- check indicator field (exact technical name not certain) - marks the object as checked with maintained values, checked without maintained values, or not checked, and is what SU24 and PFCG read when building or comparing proposals
How it joins the data model
- USOBX_C-TCD = USOBT_C-TCD and USOBX_C-OBJCT = USOBT_C-OBJCT to join the check indicator to the actual proposed field values for that object
- USOBX_C-TCD = AGR-TCODES-TCODE to find which roles include a transaction whose check indicators are being reviewed
- AGR-TCODES-AGR_NAME = AGR-1251-AGR_NAME to see which of the proposed objects from USOBX_C/USOBT_C were actually pulled into a role's authorization data
- USOBX_C-OBJCT = TOBC-OBJCT to resolve the object to its authorization object class and short text
How to read it safely
MANDT restricts to the working client; SU24 maintenance is typically done in a customizing or development client and transported, so cross-client selects without a client filter are a common source of confusion when two clients disagree. TCD is the natural entry point for a targeted lookup since a consultant almost always starts from a known transaction, not a known object. Selecting by OBJCT alone across the whole table returns a very large result set spanning every transaction in the system and is rarely the right first step. Always pair TCD with OBJCT when confirming a specific proposal rather than browsing the table unrestricted.
How to prove it in the data
A user reports being denied on a transaction despite the role showing the transaction assigned. Select USOBX_C on TCD equal to that transaction code. If the relevant authorization object is present with an indicator showing checked-but-unmaintained, PFCG never proposed field values for it, meaning the role's authorization tab will not have that object populated unless someone added it manually or via expert mode. That confirms the gap is in the proposal, not in the role assignment logic itself.
ECC vs S/4HANA
USOBX_C remains in use on S/4HANA and is still the table SU24 and PFCG rely on for check indicators; there is no CDS compatibility view replacing it because it is an internal maintenance table rather than a reporting object. Its role is unchanged, though the volume of entries grows over releases as new Fiori apps, OData services, and their underlying transactions get their own proposal entries added by SAP or by customer SU24 trace activity.
Common pitfalls
- Treating a no-check indicator in USOBX_C as if it disables the AUTHORITY-CHECK statement in the ABAP program. It does not; the indicator only controls whether SU24 proposes the object during role maintenance, and the code will still run its own check and can still deny access.
- Confusing USOBX_C with USOBT_C and editing the wrong table when trying to add a proposed authorization value; USOBX_C only carries the check indicator, the actual field values live in USOBT_C.
- Editing check indicators and assuming existing generated roles pick up the change automatically. Roles need to be reopened in PFCG and the authorization data refreshed or compared, otherwise the profile stays as it was generated before the change.
- Assuming an entry missing from USOBX_C for a given transaction means that transaction performs no authorization checks. It usually means nobody has traced the transaction with SU24 yet; the underlying checks in the code fire regardless.
- Mass-changing indicators to no-check as a quick fix for authorization failures reported by users, which stops the object from being proposed for future role builds but does nothing to remove the enforcement already compiled into the program, so the denial persists.
- Forgetting that customer changes to USOBX_C need to be reconciled against SAP's delivered defaults during an upgrade using the standard SU24 comparison step, otherwise custom check indicators can be silently overwritten or duplicated.
Whose problem this is
This is a security and role design question, owned by whoever runs SU24 and PFCG maintenance on the project, not by functional module consultants. Functional teams get pulled in only to confirm which authorization objects and values a given transaction is expected to check, since they know the business process; the actual table maintenance and transport of changes stays with security.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/usobx-cERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.