Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Extensibility: freedoms and restrictions

10 min

Listen to this lesson

0:00 / 6:38

Every company needs something the standard does not do. What differs between the options is how you may add it, and that decides whether the next upgrade is a non-event or a project. SAP's current answer to "how" is the clean core approach and, since 2025, the clean core level concept, which grades every extension from A to D.

The clean core levels in one table

LevelWhat it usesUpgrade risk
AOnly publicly released, stable interfaces: key user tools, ABAP Cloud on-stack, or side-by-side on SAP BTPLowest; designed to survive upgrades
BLevel A plus classic APIs and technologies that SAP documents as generally upgrade-stableLow
CAccess to SAP internal objects for legacy scenarios; check SAP's changelog for SAP objects before each upgradeModerate; check every upgrade
DExplicitly not recommended: modifications, write access to SAP tables, implicit enhancementsHighest; technical debt

Clean core levels as described by SAP in 2025. An extension is rated by its weakest component.

Rate an extension by its weakest component: one internal call is enough to drop it to level C.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-101

The levels replace an older three-tier extensibility model, which SAP now treats as sunset. They describe the extension, not the deployment option, but the options decide which levels you are allowed to reach.

What each option permits

In the public edition you stay at level A by design. You extend with key user extensibility (custom fields, custom logic and custom business objects built in Fiori apps), with developer extensibility on-stack in ABAP Cloud using released objects (available in the three-system landscape), and with side-by-side applications on SAP BTP that call released APIs. Modifications are simply not possible.

In the private edition and on-premise, every technique is technically available, including classic user exits, BAdIs, direct table reads and even modifications. SAP's guidance is the same as for the public edition: extend at the highest level possible, start with A, use B where needed, use C only for specific needs, and avoid D. Under RISE, clean core is built into the methodology through clean core quality gates and a dashboard in SAP Cloud ALM.

The public edition limits you to level A techniques; the private edition and on-premise allow everything, so discipline has to come from governance.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-101
Public EditionLevel A only. Little freedom, little upgrade risk
Disciplined private or on-premiseFull freedom available, but used at levels A and B. Upgrades stay predictable
Rare in practiceLow freedom with high risk usually means poor tooling, not a deployment option
Unmanaged private or on-premiseModifications and internal objects everywhere. Each upgrade becomes a project
Freedom is not the same as risk; discipline decides which box a private or on-premise landscape lands in.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-101

How clean core is checked

Levels are only useful if someone measures them. For ABAP code, the ABAP test cockpit (ATC) is SAP's main tool for code-level governance: developers run it while they work and at transport release, and its findings show where code uses unreleased or internal objects. ABAP Cloud enforces the rules for new code through its syntax checks, so a developer who tries to call an unreleased object gets an error, not a warning. Under RISE, the clean core view in SAP Cloud ALM summarizes the landscape for the program and for SAP. None of this needs a public edition; it is equally available, and equally useful, in a private edition or on-premise system.

Contoso's custom code

Contoso's ECC system carries about 11,800 custom objects, roughly 40% of them never called. Kenji, the ABAP development lead, uses the conversion to sort them: unused objects are retired, standard Fiori apps replace some reports, and the rest are adapted. The core return agreements table and its programs stay, because no standard object covers the fleet deposit process; it reads SAP sales tables directly, so it rates level C until Kenji switches those reads to released views. A handful of old ECC modifications in pricing are level D and are being removed.

  1. NeedBusiness asks for a change the standard cannot meet
  2. Fit to standardCheck configuration, standard apps and SAP Best Practices first
  3. Pick the techniqueKey user, developer on-stack (ABAP Cloud) or side-by-side on BTP
  4. Rate the levelA or B preferred; C needs a recorded justification; D is refused
  5. Record and testExtension registered with owner, level and test cases
How Contoso decides on any new extension, whatever the option.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-101

What would you do?

A business analyst asks Kenji to add a validation that blocks sales orders for Great Lakes Fleet Services when a core deposit is unpaid. Kenji could do it with a modification in the sales order program or with a released extension point. Contoso is on the private edition. What should he choose?

Key points
  • Clean core levels grade extensions: A (released only), B (classic APIs), C (internal objects), D (not recommended).
  • The public edition keeps you at level A; private edition and on-premise allow everything but SAP recommends the same discipline.
  • An extension is only as clean as its weakest component.
  • Under RISE, clean core is tracked through quality gates and a dashboard in SAP Cloud ALM.

Check your understanding · not graded

Lesson check

  1. 1. Which clean core level covers modifications and write access to SAP tables?

  2. 2. Which extension techniques are available in the public edition?

  3. 3. An extension uses released APIs except for one read of an internal SAP table. How is it rated?

  4. 4. What does SAP recommend for private edition customers who are allowed to modify?