Lesson 2 of 5
Adapting the UI
9 min
Many requests that sound like "we need a change" are really "the screen is cluttered" or "the field is in the wrong place". For these, the lightest tool is UI adaptation: a key user changes the layout of a Fiori app for everyone who uses it, without touching the data or the logic behind it.
Personalization, adaptation and extension
| Change | Who does it | Who sees it | Example |
|---|---|---|---|
| Personalization | Any user | Only that user | Saving a list filter as a variant; reordering own columns |
| UI adaptation | Authorized key user | All users of the app (or of the context it is saved for) | Hiding six unused fields on the sales order object page |
| Custom field | Authorized key user | Everyone, once added to the UI | Adding a fleet contract number field |
| Developer extension | Developer | Depends on design | New logic in a released extension point built in ABAP |
What UI adaptation can do
- Hide and show fields, groups and sections that the app already contains.
- Move fields and groups to a more logical place.
- Rename labels so they match the company's language, for example "Fleet customer" instead of "Sold-to party" on a specific screen.
- Add fields that exist in the app's data model but are not displayed by default, including custom fields once they are enabled for the app.
- Create groups or sections to cluster related fields.
You start it from the Fiori launchpad: open the app, choose Adapt UI from your user menu (the exact menu label varies by release and launchpad version), and the app switches into an editing mode where you select elements and act on them. When you save and exit, the adaptation applies to the app for its users. Depending on your release, adaptations can be saved for specific roles rather than for everyone; check your system before promising role-specific screens.
What UI adaptation cannot do
UI adaptation changes presentation only. It cannot add a field that does not exist in the data model, it cannot make a field mandatory in the business sense, it cannot change how values are calculated and it does not change what data the user is authorized to see. Hiding a field is not a security control: the data is still there, still in reports and APIs.
- Does the field already exist in the app's data?Yes → UI adaptation may be enough · No → custom field needed
- Is the need only about visibility, position or label?Yes → UI adaptation · No → next question
- Must the value be validated, defaulted or derived?Yes → custom logic (or developer extension) · No → next question
- Must the value flow to other documents, forms or interfaces?Yes → custom field with those usages enabled · No → custom field for the app only
Adaptations and upgrades
SAP designs UI adaptations to survive upgrades, because they are stored as changes layered on top of the delivered app rather than as edits to it. That does not make them immune. If SAP redesigns an app in a later release, or replaces it with a successor app, an adaptation may need to be redone. Keep a short record of each adaptation (app, what was changed, why, by whom) so it can be checked and, if needed, rebuilt after an upgrade.
Testing a UI adaptation
UI adaptations are small, but they can still break things. A hidden field might be one that a user needs for a variant of the process; a moved field might fall off the visible area on a smaller screen; a renamed label might no longer match the training material. Test an adaptation by running the scenarios that use the app with a user who holds the target role, and by checking that hidden fields are not needed in any variant.
What would you do?
Contoso's order desk asks Maria to make the "Customer reference" field mandatory on the sales order. Maria plans to do it with Adapt UI. What is the best advice?
- Personalization is per user; UI adaptation applies to all users of the app; extensions change data or logic.
- Adapt UI can hide, move, rename and add existing fields and groups.
- It cannot add new data, enforce mandatory values or restrict access.
- Test adaptations against every variant that uses the app, with the target role.
Check your understanding · not graded
Lesson check
1. Who sees a UI adaptation saved by a key user?
2. Which need can UI adaptation alone meet?
3. Why is hiding a field not a security control?
4. What should you check before hiding a field?