UI Adaptation (Adapt UI)

UI adaptation never edits the app's code. SAPUI5 flexibility records each change as a small semantic delta, for example "field Supplier Rating moved to group Delivery", attached to the stable ID of the control, and stores it in the layered repository.

At runtime, the app loads its original views and applies the stored deltas from each layer in order:

Because changes reference stable IDs rather than screen positions, they survive app updates as long as the referenced controls still exist. UI adaptation is therefore a layer of recorded changes on top of an untouched app.

• Personalization (end users). Users adjust tables, filters and views for themselves and can share views as public. Nothing changes for other users unless they pick a shared view.
• Key user adaptation (key users). From the user menu, Adapt UI opens a WYSIWYG mode with drag and drop and context menus. Key users rearrange, rename, remove or add fields and groups for everyone, and can publish the result as a separate app variant. In SAP Fiori elements for OData V4, key users can also adjust list report variants, move or rename buttons, rearrange object page sections and embed content.
• Developer adaptation (developers). An adaptation project in SAP Business Application Studio, created with SAP Fiori tools, adds fragments at extension points, controller extensions or descriptor changes. The result is an app variant with its own ID that references the original.

The three levels share one mechanism but differ in reach: UI adaptation by key users changes the app for everyone, personalization changes it for one user, and developer adaptation can change behavior.

• No code and no modification. Key users change layouts without developers, and SAP's original app stays untouched.
• Upgrade safety by design. Changes are deltas on stable IDs, kept in their own layer.
• Built-in safety net. The tool warns before risky changes such as removing a mandatory field, and changes can be undone or reset to the original app.
• Drafts and versions. As of ABAP Platform 2022, key users can save drafts, keep several versions, revert and publish a chosen version.
• App variants. One delivered app can serve different teams, for example a purchase order app variant for Alder Manufacturing's plant buyers with fewer fields.

For screen-level fit, UI adaptation is the lightest tool in SAP S/4HANA's extensibility range.

• Only apps enabled for it. An app needs supported controls and stable IDs; apps that build their UI dynamically cannot be adapted.
• Only what already exists. UI adaptation can reveal a field the service already provides, but it cannot create a new field, check or calculation. Custom fields come from key user extensibility first.
• Layout, not logic. Default values, validations and process rules are out of scope; some standard actions such as edit, save and delete are excluded from button adaptation in SAP Fiori elements.
• Desktop only. Key user adaptation requires a desktop browser and a minimum screen size.
• Classic UIs differ. SAP GUI transactions are adapted with other tools; SAP S/4HANA Cloud Public Edition offers UI adaptation for classic applications based on SAP Screen Personas.
• Overrides personalization. Key user settings can override end-user settings, so users may need to reapply theirs.

These limits keep UI adaptation safe: it reshapes screens without changing what the system does.

SAP's guidance is to adapt in a test or development system and move the result to production, because changes made directly in production can conflict with transported ones.

• SAP S/4HANA on-premise and Private Edition: when the key user publishes a version, the system asks for a transport request, which an administrator releases. Key users therefore need transport authorizations in addition to the key user role.
• SAP S/4HANA Cloud Public Edition: publishing does not ask for a transport; the changes are collected for export through a software collection.
• App variants follow the same path: publishing adds them to a transport request or software collection.

Decision criterion: if more than one person adapts the same app, agree on one owner per app, because only one key user should adapt an app at a time. UI adaptation is configuration with its own transport path, and it deserves the same release discipline as any change.

Check these causes in order:

1. Role missing. The user lacks SAP_UI_FLEX_KEY_USER or a copy of it in PFCG.
2. App not enabled. The app does not support key user adaptation, for example because it lacks stable IDs.
3. System not supporting it. The app runs on a backend or platform where UI adaptation is not available.
4. Wrong device or page. The user is on a phone or tablet, or not on the current launchpad page.

The SAP documentation names the first three as the reasons Adapt UI does not appear. A missing Adapt UI entry is almost always a role or app-enablement question, not a launchpad defect.