A frequent question about SAP S/4HANA Cloud Public Edition is whether custom work is still possible in a standardized cloud ERP. It is — but through defined, supported extensibility mechanisms rather than by modifying the core. SAP S/4HANA Cloud Public Edition provides three extensibility options: key-user extensibility, developer extensibility, and side-by-side extensibility on SAP Business Technology Platform (BTP) — which SAP now calls SAP Business AI Platform (BAIP), the AI-first evolution of SAP BTP. Each targets a different persona, a different degree of complexity, and a different degree of coupling to the ERP core. Choosing well is what keeps a landscape clean-core compliant while still meeting requirements.
The comparison stays at the level of what each mechanism is for; the governance that decides whether to extend at all is covered in the clean core strategy article, and the specific automation and integration tools have their own articles.
Key-user extensibility — for business experts. In-app low-code and no-code tools, running inside the ERP and tightly coupled to the core.
Key-user extensibility is for business experts extending the application without deep technical skills — the "last mile" of adaptation. Using in-app, low-code and no-code tools, a key user can add custom fields, adapt forms and user interfaces, create custom business objects, define custom logic through provided extension points, and build simple analytical content. The work is done inside SAP S/4HANA Cloud Public Edition itself, using released extension points, so it stays upgrade-stable by design.
Key-user extensibility fits requirements that are close to the standard: a missing field, a small UI adaptation, an additional validation, or a lightweight custom object. Its strength is speed and accessibility; its boundary is complexity, since it is not intended for large custom applications or heavy business logic.
Developer extensibility — for professional developers. On-stack ABAP Cloud code, running inside the ERP and upgrade-stable by design.
Developer extensibility is for professional developers who need more than key-user tools allow, but still want to stay on-stack and upgrade-stable. It uses the ABAP Cloud development model — a restricted, cloud-ready form of ABAP that permits only released APIs and objects — so custom code runs inside the system while remaining clean-core compliant. Developers build with released interfaces and modern ABAP in an approved environment, which gives more freedom than key-user tools without the risk of classic core modification.
Developer extensibility fits requirements that need real code and tight proximity to ERP data and logic — custom business logic, more complex custom objects, or on-stack services — but that do not warrant a separate application. Its boundary is that it operates within the released ABAP Cloud surface: what is not released is not available, which is deliberate.
Side-by-side extensibility — for separate applications. Built on SAP BTP outside the ERP and loosely coupled, running on its own lifecycle.
Side-by-side extensibility builds custom applications and services on SAP Business Technology Platform, outside the ERP, and connects them to SAP S/4HANA Cloud Public Edition through released APIs and business events. Because these extensions run on the platform rather than on the ERP stack, they are loosely coupled and operate independently of the ERP's lifecycle, and they can use the full breadth of BTP — the SAP Build tools, a developer environment, data and analytics services, and AI.
Side-by-side extensibility fits requirements that are genuinely separate from the core: a standalone application with its own user experience, an extension that must also serve non-SAP systems, a workload with a different scaling or release cadence, or anything that benefits from platform services the ERP stack does not provide. Its trade-off is that it introduces a separate runtime to design, secure, and operate.
The three options form a natural progression from closest-to-the-core to most independent. A workable selection framework asks, in order:
Two principles cut across all three. First, always prefer the option that is closest to the core while still meeting the requirement, because proximity usually means less to operate. Second, whichever option is chosen, only released interfaces are used — that is what keeps every option clean-core compliant and upgrade-safe.
SAP also publishes guidance that grades extension approaches by their alignment with clean core, which is useful when documenting the chosen option. Because these classifications and the available released interfaces evolve with each release, confirm the current position before finalizing a design.
For the governance around whether and how to extend, see [Clean core extension strategy for SAP S/4HANA Cloud Public Edition]. For process-centric extensions specifically, see [SAP Build Process Automation with SAP S/4HANA Cloud Public Edition]. For orientation on the platform, see [What is SAP Business Technology Platform (BTP) and how does it relate to SAP S/4HANA Cloud Public Edition?].