Launchpad and navigation

End-to-end Fiori automation starts in the SAP Fiori launchpad, and the launchpad adds two things a single-app test never sees: intent-based navigation and role-dependent content. Both are business risks. A broken target mapping means users cannot reach the app; a wrong role assignment means they see apps they should not, or miss apps they need. Good automation handles both deliberately instead of treating the launchpad as an obstacle to click through.

Intents, tiles and target mappings

A launchpad tile does not point directly at an app. As SAP Learning explains, it points to a target mapping through a semantic object and an action, which together form an intent. The tile's target URL is a hash such as #SemanticObject-action, optionally followed by parameters, and the launchpad resolves which app to start. Catalogs group tiles and target mappings; users get them through business roles; spaces and pages arrange them on screen.

Users reach apps through business roles: catalogs supply tiles and target mappings, and spaces and pages arrange the tiles.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-202

Tile or linkThe user clicks a tile, or a link in another app.
IntentThe launchpad reads the hash: semantic object, action and parameters.
Target mappingThe intent is matched against target mappings in the user's catalogs.
Role checkOnly mappings from catalogs in the user's business roles are candidates.
App startsThe component loads with the parameters; the app routes to its first view.

Intent-based navigation from tile to app.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-202

Two ways into an app

An automated test can reach an app by clicking through the launchpad like a user, or by navigating straight to the intent URL. Use both, for different purposes. Navigating by intent is faster, avoids depending on the tile's position on a page, and is ideal for the setup of a test whose subject is the app itself. Clicking the tile proves the user's real path: the role has the catalog, the page shows the tile, and the target mapping resolves. Keep a small set of launchpad journey tests that click, and let the rest start by intent.

	Start by intent URL	Start by clicking the tile
Speed	Fast: one navigation	Slower: home page, page, section, tile
Stability	Independent of page layout and personalization	Breaks if the tile moves or the user personalized the page
What it proves	The app works for this user and parameters	The role, page content and target mapping work too
Use for	Most functional and regression scripts	A few launchpad and role journeys per business role

Choose the entry path by what the test needs to prove.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-202

Cross-app navigation and the shell

Many Fiori processes cross apps: from a sales order to its delivery, from a supplier invoice to the purchase order. That navigation goes through the launchpad again: the source app asks for an intent, the shell resolves it and swaps the app in the same browser page. For automation this means a new component, new views and a new set of IDs, so wait for navigation to complete and locate controls in the new app's views. Remember also that the shell header (user menu, search, notifications, back button) is not part of the app. Do not anchor assertions to shell elements unless the shell is what you are testing.

Cross-app navigation swaps in a new component, so the script waits for navigation and then looks for controls in the new app.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-202

Role-dependent content

The same launchpad looks different for each user. Maria's order-to-cash role shows sales tiles; Ana's accounts payable role shows invoice processing. Automation must therefore run as role-based test users whose roles match production design, not as a super user with everything. A super user hides missing catalogs and authorization gaps, which are exactly the defects users find on day one. Use one test user per business role under test, and add launchpad assertions: expected tiles present on the expected page, unexpected ones absent, and every visible tile opening without an error.

Local and isolated testing

Developers do not need a full launchpad to test navigation. SAP provides a launchpad sandbox for local development and automated testing, explicitly not for productive use. It lets OPA5 tests start an app inside a shell-like environment, with intents configured declaratively. That keeps cross-app navigation logic testable in the developer pipeline, while your end-to-end suite checks the real launchpad configuration in CMQ.

What would you do?

Contoso's regression suite has 140 Fiori scripts. Each one logs on, opens the home page, scrolls to a section and clicks a tile. After a page redesign in CMQ, 90 fail at the tile click. What should Priya change?

Hands-on lab · ACCELQ

Open a Fiori app by tile and by intent on the S/4HANA trial

An ACCELQ Action's Destination Context records where it lands, which is how you model the launchpad handing over to an app. You'll build both entry paths this lesson compares.

Practice on SAP S/4HANA Cloud Public Edition trial (free 30-day trial with sample data; needs a free SAP account)

If you haven't set up ACCELQ yet, do the setup lab first.
Start the trial. In Resources > Global Properties, store the launchpad URL and your trial user. Keep the password out of them: make it an Action input presented as encrypted text and set its source to a Run Property, so the Run modal asks for it masked. Never share the login.
Create a Context Launchpad Home and give it Context Synchronization (Element on Page) on an element that only appears after logon. Record an Action Log on to trial, then parameterize the user (source: your Global Property) and the password as described above.
Pick any tile your trial shows. Create an Action Open app by tile with a new Destination Context for that app, and record the tile click in Fluid mode.
Open the same app by hand and copy the part of its URL from the # onward. That's the intent. Store it as a Global Property.
Create an Action Open app by intent with one Load URL in tab statement. For its value, open the expression editor and type {{$ to insert the launchpad URL property, followed by the intent property.
In both Actions, switch to Intent mode and add Verify Element Text on the app's own title so you know the app loaded and not just the shell.
Build two Scenarios that start with Initiate Browser Session and Log on to trial, one per entry path, and Run both.

Done when Both Scenarios pass. Keep the intent path for most tests and the tile path as your role-content check, and keep both Test Report links.

Learn more in ACCELQ’s docs: Defining Destination Context for an Action · Browser Tabs and Multiple Sessions · How to encrypt sensitive information such as passwords in Test Logic and Reports

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Tiles point to intents (semantic object plus action); target mappings in role catalogs decide which app starts.
Start most scripts by intent; keep a few tile-click journeys per role to prove launchpad content.
Cross-app navigation loads a new component: wait for it and locate controls in the new app.
Automate with role-based test users, never a super user, and assert both present and absent tiles.
The launchpad sandbox supports local and automated navigation tests; it is not for productive use.

Intents, tiles and target mappings

Two ways into an app

Cross-app navigation and the shell

Role-dependent content

Local and isolated testing

Lesson check