S/4HANA Extensibility: Key User & Developer Extensibility

The two-tier extensibility model - in-app key user tools versus classic/developer extensibility - for customizing S/4HANA without breaking upgrades.

SAP rebuilt how customisation works in S/4HANA, and the reason is upgrades. In the cloud editions SAP upgrades your system twice a year, and nobody gets to adjust modified code by hand first.

Key user extensibility is like using a furniture assembly kit's official accessory clips to add a shelf - simple, guaranteed to fit future kit revisions; developer extensibility is like a certified carpenter adding a custom-built cabinet using the manufacturer's approved mounting points - more powerful, still done by a professional, but still not allowed to saw into the original frame.

Key Concepts

So extensions must be built on interfaces SAP can promise not to break.

Two tiers, for two kinds of people.Key user extensibility — a business power user, through Fiori apps, without code:

    Custom Fields     add a field to a business object; it appears on
                      the UI, in forms, in reports and CDS views
    Custom Logic      add logic at predefined points, in a constrained
                      scripting model

Everything created this way is upgrade-safe by construction, because it is built through versioned extensibility APIs rather than by touching anything.

Developer extensibility — a professional developer, in ABAP Development Tools: new Fiori apps, RAP business objects, BAdI implementations, CDS extend views.

The cloud constraint that makes this real. In S/4HANA Cloud's ABAP Environment, developers may only use released APIs. Every object carries a state:

    released     SAP guarantees compatibility across upgrades
    deprecated   still works, will be removed; migrate
    not released not callable at all

That is enforced, not advised. Code against a non-released object and it does not compile.

On-premise the same released-API concept exists and is not enforced — you can still reach further into the system. Which is precisely how ECC landscapes accumulated the debt that makes upgrades expensive.

"Clean core" is the name for the principle. Keep custom code off standard objects, build on released APIs and the extensibility tiers, and keep extensions separable from the core.

The payoff is concrete: a system with a clean core upgrades on SAP's schedule. One with modifications everywhere needs a remediation project each time, which is why many ECC systems ran versions behind for years.

How to choose. Add a field and show it on a screen: key user. Add a calculation at a defined point: key user, if it fits the constrained model. A new app, a new business object, or logic that does not fit: developer extensibility, on released APIs.

Modify a standard object: only on-premise, only when nothing else works, and with a record of why — because that decision is paid for again at every upgrade.

What the interviewer is probing.1. "What is the difference between the two?" Probing: the model. Stalls: "One is harder." Moves up: key user extensibility is in-app and upgrade-safe through released APIs and custom fields; developer extensibility is ABAP in a restricted, cloud-ready environment.

2. "Why does the released API concept matter?" Probing: the upgrade argument. Stalls: "Nothing." Moves up: only released objects carry a compatibility contract, so extensions built on them survive upgrades — using unreleased internals is what breaks.

3. "What is side-by-side extensibility?" Probing: the third option. Stalls: "The same." Moves up: building the extension on BTP, calling S/4HANA through APIs, which keeps the core clean and suits anything substantial.

4. "Which would you choose for a new field on a sales order?" Probing: the practical call. Stalls: "Modify the table." Moves up: a custom field with key user extensibility, which propagates to the UI, API and reporting without code.