Custom Apps (Z-Apps)

The name comes from the ABAP naming rule: without a registered prefix namespace, repository objects created in customer systems must start with Y or Z. "Z-app" has become shorthand for any application the customer builds and owns, whatever its technology:

• freestyle SAPUI5 apps for tasks no standard app covers;
• SAP Fiori elements apps on custom CDS views and services;
• copies of SAP-delivered apps, renamed into the Z namespace and changed;
• custom transactions, reports or Web Dynpro ABAP applications launched from the launchpad;
• side-by-side apps on SAP BTP that extend SAP S/4HANA processes.

Some organizations register their own prefix namespace instead of using Z or Y, which avoids name clashes between projects. The defining trait is ownership, not the letter: a Z-app is any application whose lifecycle the customer, not SAP, is responsible for.

A typical on-stack custom app touches every layer below the launchpad:

1. Data and logic: CDS views and, for transactional apps, a business object built with the ABAP RESTful application programming model; older apps use classic ABAP.
2. Service: an OData service, published through a RAP service binding or, in older apps, built in the Gateway Service Builder (SEGW) and activated in /IWFND/MAINT_SERVICE.
3. UI: a SAP Fiori elements or freestyle SAPUI5 app, deployed to the SAPUI5 ABAP repository, where each app is stored as a BSP application with a Z or Y name.
4. Launchpad content: a tile and target mapping in a technical catalog created with the launchpad app manager (/UI2/FLPAM), referenced in a business catalog and assigned through a role in PFCG.
5. Transport: all objects travel through the transport landscape together.

Each of the five steps creates an object the customer must keep consistent later. A custom SAP Fiori app is therefore a small product with several moving parts, not a single file.

• Exact fit: a custom app can model a process step the way the business actually works, including steps SAP does not deliver.
• Differentiation: processes that set a company apart are the ones least likely to be covered by standard apps.
• Same user experience: built with SAP Fiori elements or SAPUI5, a custom app looks and behaves like SAP apps and uses the same launchpad, roles and navigation.
• Modern, upgrade-friendly options: apps built with ABAP Cloud on released APIs, or side-by-side on SAP BTP, can stay stable across upgrades.

Example: Alder Manufacturing builds a small app for its buyers to confirm Bright Freight delivery slots, a step no standard app offers, and links it from the purchase order. Where the standard ends and the process does not, a custom app is often the most direct way to close the gap.

• Ownership never ends. Every SAPUI5 upgrade, back-end release and security review touches the app. Someone must test it, fix it and know why it exists.
• Dependencies decide the cost. Apps that use unreleased SAP objects fall into the lower clean core levels and may break during upgrades; apps on released APIs carry far less risk.
• Knowledge leaves with people. Many custom apps were built by one developer or partner; when they leave, the app's purpose and logic often become hard to reconstruct.
• Copies drift. A copied SAP app does not receive SAP's fixes and enhancements, and the gap widens with each release.
• Inventory gaps. Organizations frequently cannot say how many custom apps they run or who uses them, which is a frequent complaint in practitioner communities.

These limits are not technical flaws; they are the price of owning software that SAP does not maintain.

Work down the extension ladder and stop at the first step that fits:

1. Standard: check the SAP Fiori Apps Reference Library for an app or successor that covers the need.
2. Key user extensibility: a missing field, check or default value belongs here, not in a new app.
3. App variant instead of a copy: to change an SAP-delivered app, an SAPUI5 adaptation project creates a variant that keeps receiving SAP updates; SAP supports this in Public Edition since release 2402.
4. On-stack developer extensibility: a new app on released APIs with ABAP Cloud.
5. Side-by-side on SAP BTP: when the app spans systems, needs its own data or has a different lifecycle.

A common mistake is to copy a standard app to change two fields; the fix is an adaptation project or key user extensibility. A custom app is justified when the process step itself is missing, not when a field is.

• On-premise and Private Edition: both classic ABAP and ABAP Cloud are available, so custom apps range from fully clean core to deep modifications. Governance, not the system, sets the limits.
• SAP S/4HANA Cloud Public Edition: developer extensibility lets customers build custom SAP Fiori apps in a cloud-optimized subset of ABAP on released APIs only; classic Z development with unrestricted access is not possible.
• SAP BTP: side-by-side apps live in their own subaccount and lifecycle and reach SAP S/4HANA only through APIs.

The ownership question is the same in every option; what differs is how much the platform restricts what a custom app may depend on.