The extensibility model

Every SAP S/4HANA project hears requests like "can we add a field for the fleet contract number?" or "can we hide these six fields nobody uses?" In older SAP systems the answer was usually a developer, a change request and a modification. SAP S/4HANA gives a large part of that power to trained key users, inside the system, through Fiori apps. This course explains what key users can change, how those changes move to production and, above all, what each change means for testing.

Three ways to extend

The options are not competitors. A typical project uses all three: key users add fields and adjust screens, developers build heavier logic on-stack, and separate apps on SAP BTP handle things that do not belong in the ERP core, such as a customer-facing portal. The choice depends on what the change needs to do, who will maintain it and how it should behave during upgrades.

Why SAP cares: the clean core

SAP's clean core principle says extensions should use stable, released interfaces instead of changing SAP's own code. SAP now describes extensions on a scale from level A (only released APIs and extension points, the most upgrade-stable) to level D (modifications, implicit enhancements and direct writes to SAP tables, the riskiest). An extension is rated by the riskiest technique it uses. Key user tools work through extension points that SAP has opened for them, which is why they are a natural fit for a clean core.

What key users can do

Where it is allowed

Key user extensibility only works where SAP has enabled it. Not every app can be adapted, not every business object accepts custom fields, and custom logic can only be written where SAP provides an extension point. The Custom Fields app shows which business contexts (for example sales document header or item) accept fields; the Custom Logic app lists the available extension points. On-premise and private cloud systems must also have the key user tools and their transport set up by Basis before anyone can use them. Who may use them is controlled by business roles, and it should be a small, trained group.

Who should extend

Contoso decided early that extensibility rights would go to a handful of people: one key user per process area, trained, with a named backup. Everyone else asks them. That is not bureaucracy. A key user who extends the system needs to understand the business object, the downstream documents, the forms and the reports the change touches, and needs to know how to test it. Spreading the rights widely produces duplicate fields with slightly different names, conflicting logic and screens that nobody recognizes from the training material.

A good test for whether someone should hold these rights: can they explain, for a proposed change, which scenarios must be rerun to prove it? If not, they should request the change rather than build it.