Architect / Cross-trackAdvanced

SAP Clean Core Extensibility: Key User, Developer and Side-by-Side (Part 6)

Key takeaway

Choose among key-user, developer and side-by-side extensibility by coupling, lifecycle and complexity, using the least invasive released option that satisfies the business requirement.

Explanation

S/4HANA extensibility is not one technology. Key-user extensibility is designed for controlled in-app changes such as custom fields, UI adaptations and supported simple logic where the application exposes those capabilities.

Developer extensibility covers more complex in-core extensions using ABAP Cloud, released APIs, CDS entities, RAP and released BAdIs. It is appropriate when custom behavior must participate closely in the S/4 transaction or business-object lifecycle.

Side-by-side extensibility on SAP BTP fits capabilities that benefit from an independent lifecycle, external technology stack, partner access, event-driven processing, analytics or AI. It should integrate through released APIs or events rather than internal database access.

The right choice depends on timing and coupling. A save-time compliance validation may belong in-core, while a supplier-risk dashboard combining external data is a natural side-by-side candidate.

Avoid using a more invasive option simply because the team knows it better. Start with the least coupled supported mechanism and escalate only when the requirement needs it.

Code example

ABAP Code

"Decision examples"Key-user:"- custom field"- supported simple derivation/UI adaptation "Developer extensibility:"- released BAdI"- RAP/ABAP Cloud extension "Side-by-side:"- portal, workflow, analytics, AI, external enrichment "All should use released contracts.

Real project scenario

A sales-order custom field was added through key-user extensibility, while an external partner-risk scoring application was built on BTP because it needed third-party data and independent scaling.

Common mistakes

Treating BTP as automatically cleaner regardless of API dependencies.
Using custom ABAP when key-user extensibility is sufficient.
Moving tight save-time logic to remote services without latency analysis.
Consuming unreleased APIs.
Choosing technology before understanding coupling.

Best practices

Start with the least invasive supported option.
Match extension type to transaction coupling.
Prefer released APIs and BAdIs.
Give side-by-side apps independent ownership and monitoring.
Review extensibility choices during architecture governance.

Interview angle

Compare key-user, developer and side-by-side extensibility and give an example for each.

Practice this lesson

Quick check

1. In the lesson "Clean Core and Extensibility Types", consider this project situation: A sales-order custom field was added through key-user extensibility, while an external partner-risk scoring application was built on BTP because it needed third-party data and independent scaling. Which statement is correct?

2. Scenario — A company wanted a save-time compliance validation. Which response best addresses the design or operating risk in Clean Core Extension Decision Framework?

3. What is the main goal of Clean Core?

Interview questions

1. Using this SAP project situation — A sales-order custom field was added through key-user extensibility, while an external partner-risk scoring application was built on BTP because it needed third-party data and independent scaling — explain Clean Core and Extensibility Types. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A supplier-risk dashboard combined S/4 supplier data with an external risk provider — explain Side-by-Side Extension on BTP. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.