SAP S/4HANA Cloud Public Edition Extensibility: Key User, Developer and BTP (Part 5)

SAP S/4HANA Cloud Public Edition Extensibility

What you will build

You will use a simple decision framework instead of choosing technology by habit.

Extension decision order

Use this sequence:

1. Standard process/configuration
2. Key-user extensibility
3. Developer extensibility with released cloud contracts
4. Side-by-side extension on BTP
5. Reconsider the requirement if it needs unsupported internal coupling

Key-user extensibility

Use when the requirement is local and supported by the in-app extensibility model.

Typical use cases:

• custom fields;
• custom logic in released extension points;
• UI adaptation;
• custom analytical content.

Developer extensibility

Use when professional development is required but the logic should remain close to the S/4HANA transaction.

The important principle is released APIs/objects and ABAP Cloud compatibility.

Do not depend on internal SAP tables/classes simply because a technical workaround exists.

Side-by-side on BTP

Use when the capability benefits from:

• independent lifecycle;
• different technology stack;
• cross-system process;
• external users;
• heavy integration;
• decoupling from S/4 core transaction.

Integrate through released APIs/events.

Avoid duplicate logic

Do not implement the same validation:

• in UI;
• in BTP;
• in S/4;
• in middleware

unless each layer has a clear responsibility.

The authoritative business rule should live in the correct domain owner.

Checkpoint

For any gap you should be able to state:

• why standard does not solve it;
• why the chosen extension model fits;
• which released contract is used;
• how it will be tested across upgrades.

Common mistakes

• Choosing BTP for every extension.
• Choosing on-stack logic for every extension.
• Using unreleased internals.
• Duplicating business rules.
• No owner for custom extensions.

Interview takeaway

“I choose Public Edition extensibility by coupling and lifecycle: standard first, then key-user, released developer extensibility for close transactional needs, and BTP side-by-side for decoupled/cross-system capabilities. I avoid unreleased dependencies because cloud upgrades must remain sustainable.”

A customer wants a complex supplier portal. Putting the full portal inside S/4 is unnecessary coupling. The team keeps core procurement rules in S/4 and builds the external experience side-by-side on BTP through released APIs.

• Technology-first extension decisions.\n- Unreleased object dependencies.\n- Duplicate validation in multiple layers.\n- No upgrade test ownership.

• Standard first.\n- Use released contracts.\n- Keep ownership clear.\n- Design upgrade regression for extensions.

Compare key-user, developer and side-by-side extensibility for Public Edition with one example each.