Key User, ABAP Cloud or Side-by-Side: Extending S/4HANA Public Cloud on SAP BAIP

SAP S/4HANA Cloud Public Edition can be extended in three ways: key user extensibility inside the system, developer extensibility with ABAP Cloud in the same stack, and side-by-side extensions on SAP Business AI Platform (BAIP), which since May 2026 includes what used to be SAP BTP. Side-by-side is the right choice when the extension is loosely coupled to the ERP: its own UI, its own users, its own release cycle, or data from more than one system.

TL;DR: Start with key user tools, move to ABAP Cloud when logic belongs in the ERP transaction, and go side-by-side on BAIP when the extension is a small product of its own. A clean side-by-side app uses only released APIs and events, connects through a communication arrangement and the Destination service, and authenticates users through SAP Cloud Identity Services. That keeps it at SAP’s clean core level A and lets S/4HANA upgrades pass without touching it.

My colleague Michael Suter has described the side-by-side pattern with a small Cloud Foundry app and Sofiene Karaja the in-stack route with Embedded Steampunk. This post is the decision guide in between: which option, why, and what the side-by-side architecture looks like underneath.

The three extensibility options in S/4HANA Public Cloud

SAP’s documentation on extensibility in S/4HANA Cloud Public Edition names three options and compares them in one table. In SAP’s words, key user extensibility is for “smaller low/no-code extensions”, developer extensibility for “tightly coupled more complex extensions and apps”, side-by-side for “loosely coupled extensions and apps”.

	Key user	Developer (ABAP Cloud)	Side-by-side on BAIP
Where it runs	In S/4HANA	In S/4HANA (ABAP environment)	On SAP BAIP
Typical content	Fields, logic, CDS views, business objects	RAP business objects, validations, Fiori apps	Own apps, UIs, workflows, integrations
Languages	Low code, no code	ABAP Cloud	Java, Node.js, ABAP
Coupling	Tight	Tight	Loose
Prerequisite	Key user roles	Three-system landscape	BAIP subaccount, communication arrangement

Key user extensibility covers more than most teams expect. The key user tools include custom fields, data source extensions, custom CDS views, custom business objects with their own UIs, custom logic and custom analytical queries, transported with the Export Software Collection and Import Collection apps.

Developer extensibility brings ABAP Cloud, the RESTful Application Programming Model and ABAP Development Tools into the system. One restriction decides early whether it is available at all: SAP states that developer extensibility is only available in a three-system landscape, and it uses a cloud-optimised subset of ABAP with released SAP objects only.

Side-by-side extensibility runs on the platform next to the ERP. SAP’s side-by-side documentation calls it loosely coupled but seamlessly integrated, and adds one rule worth knowing before the first sketch: a side-by-side app uses custom UI services, not the UI services SAP delivers for its own Fiori apps.

All three options read and write through the same foundation, the virtual data model with its CDS views and released APIs. That is why none of them blocks an upgrade, as long as you stay on released objects.

Clean core: what “released” buys you

SAP evolved its earlier three-tier model into four clean core levels in August 2025. Level A is “fully compliant extensions using only publicly released and stable SAP interfaces”; levels B to D allow progressively more internal access, and D is “not considered clean”. SAP’s clean core extensibility white paper places a side-by-side extension built on SAP BTP (now part of SAP Business AI Platform) with released interfaces at level A, next to ABAP Cloud on-stack.

In S/4HANA Public Cloud the choice is narrower than in a private edition anyway, because there is no modification access. The practical question is therefore not “clean or not”, but which released interface you use and where the code lives.

When side-by-side is the right choice

SAP’s Extension Architecture Guide gives a decision framework. Condensed into the questions we ask in workshops:

Question	Points to
Does the logic have to run in the same transaction as the ERP document?	ABAP Cloud
Many round trips or large data volumes per user action?	ABAP Cloud
Can a field, a rule or a key user CDS view solve it?	Key user
Do external users (customers, partners, field staff without S/4 licence) work with it?	Side-by-side
Does it combine S/4HANA data with a CRM, a webshop or a third-party system?	Side-by-side
Does it need its own release rhythm or scaling, independent of S/4HANA upgrades?	Side-by-side
Is the team stronger in Java, Node.js or TypeScript than in ABAP?	Side-by-side
Is there no three-system landscape?	Key user or side-by-side

The last row is often overlooked. A customer with a two-system landscape has no developer extensibility; anything beyond key user tools goes side-by-side by default.

What a side-by-side architecture looks like

A typical side-by-side extension for S/4HANA Public Cloud has five layers. None of them is exotic.

1. Application: CAP on Cloud Foundry or Kyma

SAP’s developer guidance recommends two programming models, ABAP Cloud and the SAP Cloud Application Programming Model (CAP). On the side-by-side route, CAP is usually the backbone: Java with Spring Boot or Node.js with JavaScript or TypeScript. CAP deploys to Cloud Foundry or to the Kyma runtime. Cloud Foundry is the simpler start; Kyma pays off when you already run containers or need Kubernetes features.

2. User interface and entry point

SAPUI5 or SAP Fiori elements for apps that should feel like S/4HANA, SAP Build Work Zone as the launchpad. S/4HANA can expose its own launchpad content to SAP Build Work Zone, so users see ERP apps and extensions side by side.

3. Released APIs through communication arrangements

Every API on the SAP Business Accelerator Hub for S/4HANA Cloud belongs to at least one communication scenario. To use it, you create a communication user, a communication system and a communication arrangement for that scenario in S/4HANA. If no standard scenario fits, the Custom Communication Scenarios app exposes your own custom CDS views. One arrangement per business purpose keeps permissions readable and decommissioning simple.

4. Events instead of polling

S/4HANA Public Cloud publishes business events through Enterprise Event Enablement. Configured with the communication scenario SAP_COM_0092, the events are sent to SAP Event Mesh in the CloudEvents format. A side-by-side app subscribes and reacts, for example when a sales order is created or a business partner changes, instead of asking the API every few minutes. That keeps it inside API limits and closer to real time.

5. Identity and authentication

S/4HANA Public Cloud uses the Identity Authentication service of SAP Cloud Identity Services (IAS) as its default identity provider, with trust configured during provisioning. Point your BAIP subaccount at the same IAS tenant and users log in once for both.

For the call from the app to S/4HANA, the SAP S/4HANA Cloud Extensibility service on BAIP supports basic authentication, OAuth 2.0 client credentials, OAuth 2.0 SAML bearer assertion, client certificates and OAuth with mTLS. The decision behind that list:

• Technical user: the app calls S/4HANA as itself. Simple, but the app has to enforce who may see what.
• Principal propagation: the SAML bearer assertion flow forwards the logged-in user, so S/4HANA applies that user’s authorisations. It requires single sign-on through IAS.

Both are legitimate. Undecided is not, because it shows up later as either a security gap or a redesign.

Typical mistakes we see

• Calling unreleased services. If an OData service is not listed as released on the Business Accelerator Hub, it can change with the next upgrade.
• Replicating the ERP into the extension. Caching for performance is fine. Holding a second copy of orders or business partners turns the extension into a second system with its own synchronisation problems.
• One catch-all arrangement. Broad scopes make audits slow and decommissioning risky.
• No stage separation. Test and production BAIP subaccounts, each with destinations to the matching S/4HANA system, are the minimum.
• Building side-by-side what a key user could do. A custom field and a rule in custom logic cost hours; a separate app costs weeks and has to be operated.

What Spadoom builds side-by-side

We build on this platform for customers and for ourselves. Engage, our suite of extensions for Sales and Service Cloud V2, runs multi-tenant on SAP BAIP. Pulse, our suite for S/4HANA Public Cloud with a production planning board, a shop floor terminal, quality checks and a master data cockpit, follows the same side-by-side pattern: Node.js services and UI5 front ends on BAIP Cloud Foundry, an approuter with XSUAA for login, and S/4HANA reached only through released APIs such as the production order, product and business partner APIs. The integration between S/4HANA Public Cloud and Sales and Service Cloud V2 runs on Integration Suite on the same platform; I described how in the Integration Suite runbook.

The one-team view helps here. Whether an extension belongs in the ERP or next to it is often decided by the CRM, the webshop or the people who will use it. Our page on SAP partner Switzerland explains how ERP and CX sit in one team at Spadoom. More on the products: SAP S/4HANA Public Cloud, SAP BAIP (formerly BTP) and SAP Sales Cloud V2.

Have a requirement that key user tools cannot cover? Talk to us and we will tell you which of the three options fits, including when the honest answer is a custom field.

Frequently asked questions

What are the extensibility options of SAP S/4HANA Cloud Public Edition?

SAP lists three: key user extensibility with built-in tools such as custom fields, custom logic and custom business objects; developer extensibility with ABAP Cloud in the S/4HANA Cloud ABAP environment, available only in a three-system landscape; and side-by-side extensibility on SAP BTP, which is now part of SAP Business AI Platform.

When should I build a side-by-side extension instead of using ABAP Cloud?

When the extension is loosely coupled: its own user interface or user group (for example external users), its own release cycle, data from several systems, or a team that works in Java or Node.js. When the logic must run in the same transaction as the ERP document, with frequent round trips or high data volume, ABAP Cloud in the stack is the better fit.

How does a side-by-side app authenticate against S/4HANA Public Cloud?

Through a communication arrangement in S/4HANA, consumed via the Destination service or the SAP S/4HANA Cloud Extensibility service on BAIP. Technical access uses a communication user, client credentials or a certificate. If S/4HANA must know the logged-in user, principal propagation uses the OAuth 2.0 SAML bearer assertion flow, which requires single sign-on through SAP Cloud Identity Services.

Does a side-by-side extension keep the core clean?

Yes, if it uses only released APIs and events. In SAP’s clean core levels, a side-by-side extension on SAP BTP, now part of SAP Business AI Platform, that consumes only released, stable interfaces is level A, the fully compliant level.