Learn how extensibility works in SAP S/4HANA Cloud Public Edition, including key user, developer, and side-by-side extensions, APIs, events, SAP BTP, and clean core best practices.
SAP S/4HANA Cloud Public Edition is built around standardisation. Instead of modifying the ERP core to reproduce every existing process, organisations are expected to adopt standard SAP functionality and use supported extension mechanisms for requirements that cannot be covered out of the box.
This does not mean businesses have to use SAP exactly as delivered. Public Edition provides several extensibility options for adapting applications, adding business logic, building applications, and connecting external systems while keeping the ERP core stable and lifecycle-friendly. SAP's extensibility model is designed around Key User Extensibility, Developer Extensibility, and Side-by-Side Extensibility.
The key challenge is choosing the right extension approach for each requirement.
A simple application or data adaptation may be addressed through Key User Extensibility. More advanced in-app development can use Developer Extensibility with ABAP Cloud. Functionality that should remain decoupled from the ERP can be developed through Side-by-Side Extensibility, commonly using SAP Business Technology Platform (SAP BTP). APIs and business events provide supported ways for these extensions to exchange data and interact with SAP and non-SAP systems.
This guide explains the SAP S/4HANA Cloud Public Edition extensibility model, its main options, use cases, limitations, implementation considerations, governance, and best practices.
SAP S/4HANA Cloud Public Edition extensibility allows businesses to adapt standard SAP applications, add custom logic, and build additional functionality through supported extension models while keeping the ERP core clean and upgrade-ready.
Need help defining the right extensibility approach?
SAP S/4HANA Cloud Public Edition extensibility is the set of supported capabilities used to adapt or extend standard SAP applications without modifying SAP's underlying standard software.
SAP provides three main extensibility approaches, each intended for a different type of requirement:
| Extensibility Approach | Typical Purpose | Main Technologies |
|---|---|---|
| Key User Extensibility | Supported in-app adaptations | Custom fields, UI adaptation, custom logic, analytical extensions |
| Developer Extensibility | More advanced extensions inside S/4HANA | ABAP Cloud, released APIs and extension points |
| Side-by-Side Extensibility | Loosely coupled applications and services outside the ERP | SAP BTP, APIs, events, application services |
APIs and events are not a separate extensibility type. They are supported mechanisms that allow extensions and external applications to communicate with SAP S/4HANA Cloud Public Edition. SAP also uses release contracts to define which APIs and objects are available for specific development and integration scenarios.
The three approaches can be used independently or combined within the same solution.
For example, an organisation might add a custom field using Key User Extensibility, implement more advanced business logic with Developer Extensibility, and connect the process to an external application through APIs or events.
Expert comment: The right choice depends on where the requirement belongs. Simple in-app changes can stay close to S/4HANA, while complex or cross-system capabilities may be better handled through Developer or Side-by-Side Extensibility.
Standard SAP cannot cover every requirement of every organisation. Businesses may still need additional data, specific process logic, tailored user experiences, or functionality that sits outside the ERP core.
Extensibility provides a controlled way to address these requirements while preserving the benefits of a standard cloud ERP environment.
Organisations can make supported changes to standard SAP applications, such as adding fields or adapting selected user interfaces.
Custom fields can capture information required for industry processes, internal reporting, compliance, or specific business scenarios.
Supported extension capabilities can introduce additional validations, calculations, or business rules that are not covered by standard functionality.
Some requirements are better handled outside the ERP. Separate applications can provide specialised functionality without adding unnecessary complexity to the S/4HANA core.
APIs and events allow Public Edition to exchange data and trigger processes across SAP and non-SAP applications.
Keeping business-specific functionality within supported extension models helps reduce dependencies on SAP standard software and makes the solution easier to maintain as SAP updates the cloud service.
Public Edition offers three main extensibility approaches. The difference is primarily where the functionality is built and how closely it needs to interact with the S/4HANA application.
Key User Extensibility is intended for relatively simple, supported adaptations that can be made through SAP's built-in extensibility tools.
Typical examples include:
The available options depend on the specific SAP application and the extension points it exposes.
Best suited for: small in-app changes that can be handled without professional development.
Developer Extensibility is used when the requirement requires more advanced development within S/4HANA Cloud Public Edition.
It uses ABAP Cloud and released SAP objects and extension points. Public Edition supports this approach in a 3-system landscape.
Typical scenarios include:
Best suited for: requirements that belong inside S/4HANA but cannot be addressed through standard functionality or key-user tools.
Side-by-Side Extensibility is used when the functionality should operate outside the S/4HANA core.
These extensions are commonly developed on SAP BTP and connected to S/4HANA through supported APIs and events. They can have their own lifecycle and are useful for capabilities that span several systems or require a separate application.
Typical scenarios include:
Best suited for: functionality that should remain decoupled from S/4HANA.
Expert comment: Think of the three options as different places for the requirement to live: inside the application for simple adaptations, inside the S/4HANA development model for advanced logic, or outside the ERP for independent applications and cross-system capabilities.
Choosing the right extensibility model depends primarily on the type of requirement and where the functionality needs to run.
| Requirement | Key User | Developer | Side-by-Side |
|---|---|---|---|
| Add a supported custom field | ✅ | ||
| Adapt a supported UI | ✅ | ||
| Add supported custom logic | ✅ | ||
| Implement complex business logic | ✅ | ||
| Develop advanced in-app functionality | ✅ | ||
| Build a dedicated application outside S/4HANA | ✅ | ||
| Combine data or processes across multiple systems | ✅ | ||
| Keep functionality independent from the ERP lifecycle | ✅ | ||
| Use ABAP Cloud for in-app development | ✅ | ||
| Use SAP BTP for side-by-side scenarios | ✅ | ||
| Build loosely coupled applications or services | ✅ |
The exact capabilities depend on the SAP application, business object, available extension points, and released APIs.
Expert comment: Start with the business requirement, then decide where the capability should live: within the application, within the S/4HANA development model, or outside the ERP core.
SAP S/4HANA Cloud Public Edition provides released APIs and business events that allow external applications and extensions to interact with SAP using supported interfaces.
APIs enable applications to exchange data with S/4HANA and, where supported, perform business operations.
Common API types include:
For example, an external e-commerce platform can use APIs to exchange sales orders, customer data, or delivery information with S/4HANA.
Business events allow other applications to respond to relevant changes in SAP.
For example, an application can receive an event when a business object is created or changed and use that notification to trigger the next step in a process.
Expert comment: APIs are used to interact with SAP; events are used to react to changes in SAP. The specific APIs and events available depend on the relevant business object and SAP release.
SAP Business Technology Platform (SAP BTP) provides the platform services that can sit around SAP S/4HANA Cloud Public Edition when a requirement goes beyond the ERP application's built-in capabilities.
Depending on the use case, BTP can provide:
Relevant services may include SAP Integration Suite, SAP Build, SAP Business Application Studio, SAP HANA Cloud, SAP Event Mesh, and SAP Datasphere.
The important point is that BTP is not required for every Public Edition extension. It becomes relevant when functionality needs to operate outside the S/4HANA application itself—for example, when a solution requires its own application, cross-system processing, or additional platform services.
Expert comment: Think of BTP as the extension platform around the ERP core, rather than another layer that every Public Edition implementation must use.
In SAP S/4HANA Cloud Public Edition, it is important to distinguish between three approaches:
For Public Edition, the focus is on configuration and supported extensibility, while direct modification of SAP standard software is not part of the intended cloud model.
Expert comment: Configuration adjusts the standard solution; extensibility adds to it; modification changes it.
Extensibility is an important part of the SAP Clean Core approach.
Clean Core does not mean eliminating business-specific functionality. It means keeping the S/4HANA core as standard as possible and placing required differentiation in supported extension layers.
The principle is simple:
Keep the core standard, and move necessary differentiation to the appropriate extension layer.
This approach helps organisations reduce dependencies on SAP standard software and maintain a solution that is easier to update and operate over time.
For Public Edition, each custom requirement should therefore be assessed not only by whether it can be implemented, but also by where it should be implemented.
Public Edition extensibility becomes relevant when standard SAP processes do not fully cover a specific business requirement. In practice, organisations typically extend the solution in a few recurring areas.
A business may need to capture information that is specific to its operations, such as internal classifications, regional attributes, industry identifiers, or additional procurement data.
Where the relevant business context is extensible, this can often be addressed through Key User Extensibility.
Some processes require additional validation, calculations, or conditional rules that are not covered by standard SAP functionality.
Depending on the requirement and available extension points, this may be handled through Key User or Developer Extensibility.
Businesses may need additional steps around approvals, notifications, or exception handling.
For example, a company might require a custom approval flow for high-value purchases or a notification process when a specific business condition is met.
Depending on the scenario, this functionality can be implemented within S/4HANA or through capabilities around it, including SAP BTP.
Some capabilities are better delivered as separate applications rather than added to the ERP itself.
Examples include:
These are potential Side-by-Side Extensibility scenarios, commonly built on SAP BTP.
Standard SAP processes may need to be complemented by functionality specific to a particular industry or operating model.
Examples can include specialised business rules, additional process steps, or industry-specific applications that differentiate the organisation without requiring changes to the ERP core.
Organisations may also need tailored analytical applications or dashboards that combine S/4HANA information with data from other sources.
These scenarios can be addressed through supported analytical extensions or separate solutions depending on where the data and logic need to reside.
Expert comment: Extensibility is most valuable when it addresses a genuine business gap. The objective should be to add the capability the business needs without making the ERP core responsible for functionality that belongs elsewhere.
Having extensibility capabilities does not mean every requested change should be implemented. Organisations should establish a governance model to evaluate each requirement before development begins.
A practical review should consider:
This creates a controlled decision process and helps prevent unnecessary extensions from accumulating across the SAP landscape.
Even with the right extensibility framework, organisations can create unnecessary complexity through poor design decisions.
A requirement should not automatically lead to development. First check standard functionality, available configuration, and supported extension points.
Existing customisations should be reassessed as part of the move to Public Edition. Some may no longer be needed, while others may be better addressed through standard functionality or a different extension approach.
Not every business capability belongs in S/4HANA. Functionality that requires its own application, lifecycle, or cross-system processing may be better suited to a side-by-side solution.
Custom solutions should rely on released APIs, events, and extension points rather than technical workarounds or direct dependencies on SAP internals.
Custom development can also go too far in the other direction. A separate application should have a clear business justification and should not duplicate functionality already available in SAP.
An extension needs to be managed throughout its lifecycle. Ownership, documentation, testing, monitoring, maintenance, and eventual retirement should all be considered from the start.
Define the business problem, expected outcome, and value before selecting a technical solution.
Assess the requirement consistently across standard functionality, configuration, and the available extensibility options.
Consider how the extension will be supported, tested, monitored, and updated as the SAP environment evolves.
Assign both business and technical owners so that responsibility does not disappear after go-live.
Keep a central record of:
Reassess extensions over time. A custom solution that is justified today may become unnecessary when SAP introduces equivalent standard functionality.
Practical insight: Before approving an extension, document the business reason, the chosen approach, the owner, and the long-term maintenance plan. This creates a clear basis for deciding which extensions should be built and which should not.
Extensibility decisions should be made during solution design, before development begins.
Document the business need, expected outcome, and reason standard functionality is insufficient.
Check standard functionality, configuration options, and available extension points before choosing custom development.
Select the most appropriate option based on where the capability needs to run:
APIs and events should also be identified where the extension needs to exchange data with other systems.
Define how the extension will interact with S/4HANA, other applications, data, security, and users.
Develop the extension using supported SAP technologies and test it within the complete business process.
Define ownership, monitoring, support, maintenance, and release testing before the extension goes live.
Practical insight: Design the extension's full lifecycle before development starts. This makes it easier to control both the initial solution and its long-term impact on the SAP landscape.
There is no standard price for Public Edition extensibility. The cost depends on the type of extension, development effort, integrations, and any SAP BTP services required.
| Scenario | Relative Effort |
|---|---|
| Simple key-user adaptation | Low |
| Multiple fields, UI changes, or simple logic | Low to medium |
| Complex developer extension | Medium |
| Side-by-side application | Medium to high |
| Multi-system application and integration | High |
The overall investment may include business analysis, architecture, development, BTP services, integration, security, testing, deployment, and ongoing support.
Practical insight: Estimate extension costs together with their long-term operating requirements. A solution with a lower development effort may still be more expensive if it creates significant integration or maintenance overhead.
Public Edition does not provide the same level of unrestricted customisation as traditional SAP environments. Some legacy requirements may therefore need to be redesigned rather than reproduced.
Developer and integration scenarios depend on the SAP objects, APIs, and extension points released for the relevant use case. Not every internal SAP capability is available for custom development.
Side-by-side extensions can introduce additional applications, services, security, integration, and operational responsibilities. The business value of the additional architecture should therefore justify the complexity.
Developer Extensibility requires expertise in ABAP Cloud and SAP's cloud development model, while BTP-based solutions may require additional application-development and integration skills.
As the number of extensions grows, organisations need clear ownership, documentation, and lifecycle management to prevent the application landscape from becoming unnecessarily complex.
The key question is:
Does this capability need to live outside the ERP application?
Side-by-side extensibility is often appropriate when the requirement:
SAP describes Side-by-Side Extensibility as a model for loosely coupled applications and extensions that can operate independently of the S/4HANA lifecycle.
For example, a supplier portal that combines SAP procurement data with external supplier information may be better implemented as a separate BTP application than as functionality embedded directly in the ERP.
Practical insight: Use Side-by-Side Extensibility when the business capability needs independence, not simply because the requirement is difficult to implement in S/4HANA.
Before approving an extension, confirm:
Public Edition supports configuration and controlled extensibility rather than unrestricted modification of SAP standard software.
SAP defines three main approaches: Key User Extensibility, Developer Extensibility, and Side-by-Side Extensibility.
Key User Extensibility is intended for supported in-app adaptations, while Developer Extensibility is used for more advanced development with ABAP Cloud and released SAP objects.
No. SAP currently documents Developer Extensibility as requiring a 3-system landscape.
Side-by-Side Extensibility means building loosely coupled applications or services outside the S/4HANA core, commonly on SAP BTP, and connecting them through supported interfaces.
No. Key User and Developer Extensibility can address requirements within S/4HANA. BTP is particularly relevant when the solution needs side-by-side applications, broader integration, automation, or other platform services.
APIs provide supported interfaces for exchanging data and performing supported operations, while business events allow applications to react to changes in SAP. The exact interfaces available depend on the relevant released object and use case.
Supported extensibility allows organisations to add business-specific functionality without changing SAP standard software, helping reduce dependencies on the ERP core.
Not automatically. Legacy customisations should be assessed individually to determine whether they should be replaced by standard SAP, redesigned, extended, moved outside the ERP, or retired.
Yes. Public Edition supports integration through released APIs, events, and integration technologies. SAP documents these interfaces for both integration and side-by-side scenarios.
Yes. Developer Extensibility uses ABAP Cloud and SAP's released-object and extension-point model for cloud-ready development.
Assess the business requirement, standard SAP functionality, available extension points and APIs, target architecture, ownership, security, and long-term maintenance implications.
SAP S/4HANA Cloud Public Edition does not remove the need for business-specific functionality. Instead, it provides a structured extensibility model that allows organisations to differentiate without relying on unrestricted modification of the ERP core.
The three approaches serve different needs:
Key User Extensibility for supported in-app adaptations,
Developer Extensibility for more advanced ABAP Cloud development within S/4HANA, and
Side-by-Side Extensibility for loosely coupled applications and services outside the ERP core.
The important decision is therefore not whether an organisation can build an extension, but whether it has chosen the right location, architecture, and lifecycle for that capability.
LeverX helps organisations assess Public Edition requirements and define the right approach across Key User Extensibility, Developer Extensibility, SAP BTP, APIs, and integrations.
We recommend starting with an extensibility assessment to identify which requirements can be handled by standard SAP and which need configuration, development, or a side-by-side approach.
Disclaimer: SAP, SAP S/4HANA, SAP BTP, ABAP Cloud, and other SAP product and service names referenced in this article are trademarks or registered trademarks of SAP SE or its affiliates. Product features, functionality, APIs, extension points, services, availability, licensing, pricing, and release-specific capabilities may change over time. The information provided in this article is for general informational purposes only and is based on publicly available information at the time of publication. It does not constitute official SAP documentation, legal, tax, financial, or professional advice. Organisations should verify applicable SAP functionality and requirements against current SAP documentation and their specific business and technical environment before making implementation or investment decisions.