Skip to content
Atlas docs

Clean core

“Clean core” is SAP’s name for a principle that turns out to be the main organizing idea for where Atlas is willing to put the code it generates. The idea is small enough to summarize in one sentence: the standard S/4HANA core is not modified, and every customization lives on BTP, reaching the core through published APIs.

Clean core SAP BTP · extension surface customizations, side-by-side apps, custom fields, workflows S/4HANA core standard objects · not modified upgrades stay quarterly releases stay compatible Custom field Key-user extension Workflow Process extension Side-by-side Node / Python svc Fiori app BTP-hosted SPA Extensions reach the core only through published APIs. The core itself is never modified.
Clean core — extensions live on BTP, reached through published APIs.

What the principle actually asks

Section titled “What the principle actually asks”

Two things. First, do not change SAP-owned code — no overwriting of standard reports, no implicit extensions that mutate released objects, no direct edits to released CDS views. Second, do not reach into the core through unpublished surfaces. If there is no A_ view or released service binding for the data you need, it is not meant to be a public dependency.

The payoff is that upgrades stay tractable. When SAP ships a quarterly release, a clean-core system inherits the changes without a migration project; a system with modifications has to re-apply every modification against the changed surface, and something always drifts.

Where Atlas makes the call

Section titled “Where Atlas makes the call”

Every plan Atlas emits includes a decision about which system the artifact lives in — the S/4HANA core or BTP. That decision is not cosmetic; it changes every downstream constraint.

Core or BTP? The placement call 1 · Can a released VDM view answer it? A_ or C2 I_ / C_ that covers the fields you need no yes 2 · Do you need writes or custom logic? behaviors, workflows, side-effects yes no BTP side-by-side service calls core via A_ API BTP key-user extension extends released views 3 · Is this a read-only projection? a view that projects existing data only no yes BTP workflow or side-by-side app S/4HANA core clean C_ view on released I_ views Three greens in a row is the only combination that puts an artifact in the core. Every other path keeps the core untouched — that is the definition of clean core. Override: atlas placement override --target core --reason "…" The override carries on the transport and in the evidence trail.
The placement call — three binary questions determine core vs BTP.

The tree is deliberately short. Most artifacts Atlas plans fall out of the first question: if a released view covers the request, the core is fine; if not, the conversation is already about BTP.

If the artifact is a read-only view Atlas can express against a released basic-interface view, the core is a safe home. Atlas emits a C_ consumption view that consumes I_ views in the usual way, and the upgrade contract with SAP protects the result.

If the artifact needs a field the released views do not expose, or a join across modules the VDM does not stitch together, or custom logic that the VDM cannot represent, the core is the wrong home. Atlas moves the artifact to BTP — as a side-by-side service, a Fiori extension, or a workflow — and wires it to the core through the published APIs that do exist.

What you will see Atlas do

Section titled “What you will see Atlas do”

When a plan renders in the Studio canvas, one of the early nodes is a placement decision. Click it and the inspector shows the core-versus-BTP call plus the evidence that drove it. For a read-only analytics view against released data, placement is usually trivial and tier-1. For an extension that needs a non-released field, placement is explicit — and the extension will be generated for BTP even if you did not ask, because emitting it into the core would violate clean core and Atlas will not do that.

If you disagree with the placement, you override it from the placement node itself and write a reason that travels forward with the plan’s evidence — the same pattern every override in Atlas follows. Gates are non-bypassable explains why the ceremony is worth the extra keystrokes.

The practical consequence

Section titled “The practical consequence”

Plans for clean-core systems are almost never smaller than plans that ignore the principle, because the BTP side has to be real — a service to deploy, a workflow to wire, a Fiori app to host. But they are almost always less work on the next upgrade. Atlas makes the trade-off explicit in the plan itself, so the conversation about it happens once, up front, rather than quietly later when an upgrade breaks.