S_TABU_CLI — Cross Client Table Maintenance Authorization
S_TABU_CLI is a second gate checked in SM30 and SM31, in addition to S_TABU_DIS or S_TABU_NAM, for tables whose technical settings are flagged as cross-client relevant. It controls whether a user may change data in a table that affects every client in the system, not just the client they are logged into. Missing it causes a failure even when the table's own authorization group check succeeds.
This page covers what S_TABU_CLI actually restricts, why a role with perfectly correct S_TABU_DIS entries can still fail table maintenance, and how to isolate the missing check using SU53 and the authorization trace. It also covers the risk profile security teams weigh before granting this object, since it is not table-specific.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 884 words
What it protects
S_TABU_CLI guards maintenance of tables that are flagged, in their technical settings, as cross-client (client-independent). Changing a row in such a table from one client changes it for every client on that system. The structural fact that causes most confusion: this object does not replace S_TABU_DIS or S_TABU_NAM, it sits alongside them. A user maintains a table through the generated maintenance dialog and the system runs both checks in the same call. S_TABU_DIS or S_TABU_NAM controls access based on the table's authorization group; S_TABU_CLI controls access based purely on whether the table itself is marked cross-client relevant, regardless of authorization group. A role can have full rights to the authorization group and still be blocked here because the cross-client flag is a separate property of the table, set once by SAP or by whoever created the table, not something the requesting user chose.
Fields checked
- CLIIDMAINT - the single field on this object, holding a flag value that permits or blocks maintenance of tables marked cross-client relevant; treat the exact technical name as needing confirmation against the system's own authorization object display before quoting it in a role change request.
- There is no ACTVT field on this object in the usual sense found on S_TABU_DIS; the check is essentially a yes-or-no gate rather than an activity-differentiated one, so the practical question when troubleshooting is simply whether the value the user has matches the value the check demands, not which activity was attempted.
Where it is checked
- SM30 and SM31, the standard single-table maintenance transactions, when the table being opened has the cross-client maintenance flag set in its technical settings.
- SM34, view cluster maintenance, when any table inside the cluster carries the cross-client flag.
- Generated maintenance dialogs invoked from custom transactions built with the table maintenance generator, since the check is embedded in the generated maintenance framework itself, not in the calling transaction's own code.
- The check fires after S_TCODE has allowed entry into the transaction and after S_TABU_DIS or S_TABU_NAM has evaluated the table's authorization group; it is the last gate in the chain, so a failure here means the earlier checks already passed.
How to trace a failed check
Start with SU53 immediately after the failed save or the blocked entry into change mode; because SU53 only shows the most recent failed check for the user's session, run it right away rather than after navigating elsewhere. Look specifically for S_TABU_CLI in the displayed object, and compare the value the check demanded against what the user's roles carry, or whether the object is absent from every assigned role entirely, which is the far more common finding than a value mismatch. If SU53 shows nothing useful, or the user reports the problem secondhand, ask them to reproduce it while an authorization trace runs, using the trace transaction, then filter the trace output to this object and this user. Hand security the table name, the transaction used to reach it, confirmation from SE11 or SE13 that the table's technical settings carry the cross-client maintenance flag, and the specific reason the change must happen from this client rather than through a transport. Do not hand over a generic 'grant S_TABU_CLI' request without that context.
Whose problem this is
This sits with security, not the functional team, because granting S_TABU_CLI is a system-wide risk decision rather than a scoped data-access decision; the object does not distinguish by table, so one grant opens every cross-client table the maintenance framework protects this way. A good request states the table, the transaction, the business reason the change cannot wait for a transport, and a target end date if the access is temporary.
Common pitfalls
- A role has correct S_TABU_DIS entries with the right authorization group and activity, and the user still cannot save changes; the missing piece is S_TABU_CLI, which many role designers forget entirely because it rarely appears in standard SAP-delivered composite roles.
- Someone concludes the authorization group is wrong and widens S_TABU_DIS further, which does nothing for this failure and quietly increases access to unrelated tables sharing that group.
- S_TABU_CLI is confused with client-independent customizing requests or with cross-client transport settings; those are transport landscape concepts, this is a runtime maintenance-dialog check.
- The check only fires for tables that actually carry the cross-client flag, so testing succeeds on most tables in a role's normal working set and only surfaces the gap when someone touches a specific cross-client table for the first time, often during an incident rather than during role design.
- The reflex fix of unflagging the table's cross-client maintenance setting in its technical settings removes the safeguard for every user of that table, not just the one who was blocked, and should not be treated as an authorization workaround.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-tabu-cliERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.