S_ADMI_FCD — S_ADMI_FCD System Administration Function Check
S_ADMI_FCD controls a wide set of client-independent system administration activities such as spool administration, external OS command maintenance, number range maintenance, and cross-client table changes. It has one field, also called S_ADMI_FCD, whose value identifies the specific admin function requested. A user can hold this object and still fail, because the role was built with the wrong function value for the action being performed.
This page covers what S_ADMI_FCD actually gates inside SAP's basis-level administration transactions, why a role containing the object still throws an authorization error, and the sequence a consultant should follow through SU53 and trace before escalating to security. It also lists the field values most commonly involved and the pitfalls that waste time when this check fails.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 901 words
What it protects
S_ADMI_FCD is the general-purpose gatekeeper for basis-level administration work that does not belong to a more specific object. Spool administration, external operating system command maintenance, number range maintenance, print administration, and certain cross-client table maintenance actions all route through this single object. The field carries a short code identifying which specific administrative function is being attempted, and that code is what actually gets checked, not the object name itself. This is the structural fact behind most confusion: a role can legitimately contain S_ADMI_FCD with one value, say the code for print administration, and still be denied when the user tries an unrelated administrative action, say number range maintenance, because that is a different field value entirely. Consultants who see 'the user has S_ADMI_FCD in their role' and assume the object is satisfied are looking at the wrong level of detail.
Fields checked
- S_ADMI_FCD - the administration function code being requested. Common values include SPAM/SPAT for spool administration, PADM for print administration, TABL for maintenance of cross-client tables, EXTC for maintenance of external operating system commands, NADM for number range object maintenance, and ST0R for archive and storage administration functions.
- ACTVT is not normally used on this object; the function code carried in S_ADMI_FCD itself already narrows the activity, so most authorization checks against it test only that one field.
Where it is checked
- Spool administration screens (spool device and output request maintenance) check the SPAM/SPAT or PADM value before allowing changes to spool devices or held output.
- External command maintenance (the transaction for defining OS-level commands SAP can call) checks the EXTC value before a command definition can be created or changed.
- Number range maintenance transactions check the NADM value at the point of saving a new or changed number range object.
- Client copy and client administration flows check a table-maintenance-related value (TABL) when the action touches cross-client tables, even though entry into the transaction itself may not require it.
- Archiving administration transactions check ST0R or a related value when starting or scheduling an archiving job, separate from the check for the archiving object itself.
- The check typically fires at the point of the specific action inside the transaction (save, execute, schedule), not always at transaction start, which is why SU53 taken right after entering the transaction can look clean while the real failure happens two screens later.
How to trace a failed check
Run the failing action, then go straight to SU53. If it shows S_ADMI_FCD, note the exact field value it wanted, not just the object name. If SU53 is blank or shows an older, unrelated failure, the check likely happened in a background call or a step after the screen SU53 is reading from; switch to the authorization trace transaction and repeat the action with the trace running, then filter the trace output to S_ADMI_FCD entries. Capture the user id, the transaction or program, the timestamp, and the specific field value from the trace. Hand the security team that value and the business action it corresponds to, not a request to add the object generically. If the trace shows multiple S_ADMI_FCD checks with different values across one transaction flow, list all of them, since the role will need every value the flow touches, not just the first one that failed.
Whose problem this is
This is a security team change, but the functional consultant has to supply the exact field value and the business justification, since S_ADMI_FCD covers powerful system-level functions. A good request names the transaction, the specific administrative action attempted, the field value confirmed from trace, and why the user's job requires that particular function rather than the object as a whole.
Common pitfalls
- A role can contain S_ADMI_FCD with a single value copied from a template role, giving the impression the object is covered, when the failing action actually needs a different value entirely.
- SU24 default check indicators for a transaction sometimes exclude S_ADMI_FCD or mark it as not checked, so the object never appears when the role is built from proposed values, even though the underlying program enforces the check at runtime.
- The reflex fix of granting S_ADMI_FCD with a wildcard value fixes the immediate error but hands the user every administrative function the object covers, including ones with no relation to their actual task; this is usually flagged in any later audit.
- Composite or collective roles assembled from several single roles often end up with an inconsistent mix of S_ADMI_FCD values, so a user gets spool administration through one role and is still missing number range maintenance because no single role in the mix carried that value.
- A failed check is sometimes misread as a missing transaction authorization (S_TCODE) issue, when the transaction itself opens fine and the denial only happens on the specific save or execute action inside it.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-admi-fcdERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.