Clean-core extensibility is one of the most asked S/4HANA topics. Interviewers want upgrade-safe customizations and the right extension pattern. These are the questions that keep coming up.
Clean Core Concepts
What does "clean core" mean in S/4HANA?
Clean core means keeping the SAP standard codebase free of modifications so upgrades move fast. Custom logic lives in defined extension points instead of modified SAP code. The goal: quarterly upgrades that do not break customizations.
What is the difference between in-app and side-by-side extensibility?
In-app extensibility happens inside S/4HANA using released extension points: custom fields, custom business objects, key-user adaptations. Side-by-side builds separate apps on SAP BTP consuming S/4HANA APIs and events. In-app is for close-to-core tweaks; side-by-side is for new processes and UIs.
What is a released API and why does it matter?
A released API is an OData service, CDS view, or function module SAP commits to keeping stable across upgrades. Building on released APIs is the core clean-core discipline. Unreleased objects can change without notice and break your extensions.
How do you check whether an object is released for extension?
Use the Extensibility Inventory app or the API documentation on the SAP Business Accelerator Hub. In ABAP Development Tools, repository objects show their release contract info. Never assume — always verify before building on an object.
Key-User vs Developer Extensibility
What can a key user do without a developer?
Key users create custom fields, adapt UIs, build custom business objects, and define custom CDS views with the in-app tools. These no-code and low-code options cover a large share of typical requirements. Know the Custom Fields and Custom Business Objects apps by name.
When do you need developer extensibility instead?
When the requirement exceeds key-user tools: custom logic in BAdIs, complex CDS views, custom OData services, or RAP business objects. Developer extensibility uses released enhancement spots and BAdIs. Rule of thumb: the simplest released option that meets the requirement.
What is the difference between runtime UI adaptation and adaptation projects?
Runtime adaptation (key-user, in the live app) creates personalizations or variants quickly for small changes. Adaptation projects in Business Application Studio or ADT bundle larger UI changes with transport management. Projects suit lifecycle-managed changes; runtime suits quick tweaks.
Key takeaway: key-user tools first, developer extensions only when needed, everything on released APIs. That one sentence answers half the extensibility questions you will face.
Technical Extension Points
What are the main BAdI enhancement options in S/4HANA?
Classic BAdIs and enhancement spots still exist, but clean-core guidance favors released BAdIs documented for the specific business context. Custom BAdI logic must avoid modifying standard tables directly. Always check the enhancement spot's released status first.
What is RAP and where does it fit?
The ABAP RESTful Application Programming Model is the recommended way to build transactional services on S/4HANA, for Fiori apps and APIs alike. Managed and unmanaged scenarios define behavior, draft handling, and validations declaratively. New custom business logic should default to RAP on released CDS views.
How do custom fields reach Fiori UIs and APIs?
Custom fields from the Custom Fields app are enabled per business context, then exposed to UIs via adaptation and to APIs by extending the service. The field lands in the released extension include, so it survives upgrades. That upgrade safety is the point interviewers probe.
What are extension includes and why do they matter?
Extension includes are append structures SAP reserves in standard tables for customer fields. Appending there instead of modifying the table keeps the core untouched. During upgrades SAP preserves appends — exactly the clean-core behavior you want.
Events, Integration, and Governance
How does event-driven extension work in S/4HANA?
Business events (like a sales order being created) publish to the event infrastructure, where side-by-side extensions subscribe. This decouples custom processes from the core system. It is the preferred pattern for reacting to S/4HANA changes without touching S/4HANA code.
What is the role of SAP BTP in S/4HANA extensibility?
BTP hosts side-by-side extensions: CAP or ABAP environment services, integration flows, and custom Fiori apps. It provides destinations, connectivity, and event mesh so extensions stay off the core. Interviewers expect you to place each extension type on the right side of the in-app vs side-by-side line.
How do you keep extensions upgrade-safe in practice?
Build only on released APIs, CDS views, BAdIs, and events; avoid modifications and unreleased objects; run the Custom Code Analyzer and ABAP Test Cockpit clean-core checks. Treat violations as findings to remediate, not warnings to ignore. Governance is what makes clean core real.
What is the Custom Code Analyzer used for?
It scans custom ABAP for S/4HANA compatibility and clean-core violations: modifications, unreleased object usage, deprecated statements. Run it before upgrades and during development. It is the standard answer for "how do you prepare custom code for an upgrade."
Key takeaway: state the requirement, pick in-app or side-by-side, name the released API or extension point, mention the governance check. Practice answers in that order.
Have an extensibility scenario from a real interview? Share it in the comments.