SAP Fiori UAT: How to Test the Launchpad, Roles, and Apps Before Go-Live

SAP Fiori is the interface your end users will open on the first morning after go-live. For most S/4HANA deployments, it's what the business will judge the entire project on — not the underlying configuration, not the data migration, not the integration landscape. If the launchpad is wrong, the go-live is wrong.

Yet Fiori is consistently the most undertested area in SAP UAT programmes. Test scripts from system integrators focus on backend transaction codes. UAT cycles run by developers confirm that tiles load. Neither approach tests what matters: whether the right apps appear for the right users, and whether those apps actually complete their workflows end-to-end against production-representative data.

Why Fiori UAT is not the same as backend SAP testing

SAP Fiori role configuration is maintained separately from backend authorisation objects. This is the root cause of most Fiori go-live failures: a user's backend roles can be perfectly configured, with correct transaction access and organisational unit assignments, while their Fiori launchpad shows a blank page or a subset of the tiles they need.

The separation exists because Fiori access is controlled by two independent configuration layers:

• —Backend authorisation objects — control what data and transactions the user can access in the S/4HANA core
• —Fiori catalogue and group assignments — control which tiles appear on the launchpad and in which section
• —OData service authorisations — control whether the Fiori app can retrieve and post data via the backend API layer

A gap in any layer produces a different failure mode: a missing tile, an app that loads but shows no data, or an app that appears to complete a workflow but fails to post in the backend. Only end-to-end scenario execution — by a user with the actual role assignment, running the full workflow to a posted document — detects all three classes of failure.

What Fiori launchpad UAT must cover

Tile visibility by role persona

Every business role persona defined in the role matrix must be tested individually. Tile visibility testing confirms that the correct tiles appear — no more and no fewer than the role should have. Common failures include:

• —Missing tiles where the catalogue or group assignment was not added to the composite role
• —Excess tiles exposed through role overlap in composite assignments, giving users access to functions outside their authorisation boundary
• —Tiles present but non-functional because the underlying OData service authorisation is missing
• —Tiles that navigate to the wrong object or open with incorrect default filter values

Composite role inheritance

Most enterprise SAP deployments assign access via composite roles rather than single roles. Composite role UAT must test the combined assignment as a unit — not the component single roles in isolation — because launchpad behaviour is determined by the full role set the user holds.

The specific risk with composite roles: individual single roles within the composite may have been tested and signed off, while the composite as a whole produces a conflicting or incomplete launchpad. This happens when catalogue and group assignments are added to some single roles but not others, leaving gaps that are invisible until the composite assignment is tested as a whole.

App workflow execution

Confirming a tile loads is not a UAT pass. Every Fiori app in scope must be tested to the end of its workflow: the full sequence of screens, the submission of the business transaction, and the verification that the correct document is posted in the S/4HANA backend.

• —Procure-to-pay apps: purchase requisition creation through to approval routing — confirm the approval task appears in the approver's My Inbox tile
• —Finance apps: journal entry posting through to GL document creation — confirm document number, posting date, and cost centre attribution are correct
• —Inventory apps: goods receipt posting through to material document — confirm the stock update is reflected in real time
• —Reporting apps: analytical tiles and embedded SAP Analytics Cloud reports — confirm data loads for the user's authorised organisational scope

Mobile device testing in Fiori UAT

For deployments where Fiori apps are used by warehouse, field service, logistics, or production floor staff on tablets or RF scanners, desktop browser testing is insufficient. Fiori's responsive design adapts to screen size, but the mobile use case introduces failure modes that don't appear on desktop:

• —Touch interaction patterns that differ from mouse-click flows — particularly in date pickers, search fields, and multi-select filters
• —Barcode and QR scan integration — if the app is configured to accept scanner input, this must be tested with the actual scanner hardware
• —Network latency on warehouse Wi-Fi — app timeouts and error handling under degraded network conditions
• —Screen orientation — some Fiori apps behave differently in portrait versus landscape mode on tablets
• —Offline capability — if the deployment includes offline Fiori apps, reconnect and sync behaviour must be tested with realistic data volumes

Mobile Fiori UAT must be conducted on the device model and operating system version that will be in production use, connected to the network infrastructure that will serve the production environment. A test on an office Wi-Fi network with a developer's personal device does not validate the production scenario.

Personalisation and configuration persistence

Fiori allows users to personalise their launchpad: reorder tiles, create custom groups, pin favourite apps. In enterprise deployments, administrators also apply group-level layouts that are pushed to user launchpads. The UAT risk is conflict between admin-applied layouts and user personalisations — a conflict that typically isn't visible until users begin modifying their launchpads post-go-live.

Personalisation UAT should cover:

• —Confirm that admin-applied group layouts appear correctly for new users before personalisation
• —Confirm that user personalisation changes persist across sessions and are not reset by role changes
• —Confirm that a role assignment update (adding or removing a role) correctly adds or removes tiles without destroying existing personalisation
• —Test personalisation behaviour when a user logs in from a different device — Fiori personalisations are stored server-side and should be consistent across devices

The most common Fiori UAT defects by category

Authorisation gaps

The tile appears on the launchpad but the app fails to load data or returns a blank screen. The cause is a missing authorisation object — typically an OData service authorisation or a backend PFCG object that was present in the test role but not included in the production composite role. These defects are invisible in role matrix review and only surface during app execution testing.

Silent backend failures

The Fiori app completes its workflow without an error message, but the document is not posted in the backend. This happens when the Fiori UI layer accepts the submission but the OData call to the backend fails silently — the app shows a success message while the backend logs an error that nobody sees. Testing must include verification in the backend transaction that the document exists, not just confirmation that the Fiori UI reported success.

Integration timing failures

Some Fiori app workflows trigger downstream integration events — IDocs, RFC calls, workflow tasks. Fiori UAT must confirm that these downstream events are triggered correctly and that the results are visible in the recipient system or workflow inbox within the expected timeframe. A goods receipt posted through Fiori that fails to trigger the corresponding IDoc to a third-party WMS is a go-live defect that end-to-end UAT would have caught.

“SAP Fiori is what your users will judge the entire go-live on. If the launchpad is wrong on day one, nothing else matters. Test Fiori as the primary surface — not as a layer on top of the 'real' UAT.”

Running Fiori UAT alongside backend process UAT

Fiori UAT should not be treated as a separate workstream from backend process UAT — it should be embedded into the same scenario execution. When a UAT tester runs the procure-to-pay process, they should run it via the Fiori apps their role would use in production, not via the backend transaction codes. This approach validates both the backend process and the Fiori presentation layer in a single test execution.

The exception is pure role and tile visibility testing — checking that a user sees exactly the tiles their role entitles them to, and no others. This should be run as a discrete test before process UAT begins, so that defects in role configuration are identified and resolved before process testers encounter them mid-scenario.

When to bring in specialist Fiori UAT resource

Fiori UAT requires testers who understand both the business role they are testing and the Fiori configuration model. A business user who can execute the process but doesn't understand composite roles will miss configuration defects. A technical tester who understands roles but doesn't know the business process will miss workflow failures.

Specialist Fiori UAT resource is most valuable when:

• —The deployment has a large role matrix with many composite roles, increasing the probability of tile visibility gaps
• —Fiori apps are being used in mobile or offline scenarios where desktop testing is insufficient
• —The organisation is upgrading from SAP GUI-based ECC to Fiori-first S/4HANA — users have no prior Fiori experience to draw on
• —Previous go-lives on the same platform produced Fiori defects that weren't caught in internal UAT
• —The compliance or operational risk of incorrect role-based access is high — particularly in regulated environments where role boundary failures create audit exposure