Target Mapping

Every navigation in the SAP Fiori Launchpad is a request for an intent, not for a specific app. The resolution runs in five steps:

1. A tile, a link or another app fires an intent: a semantic object plus an action, optionally with parameters such as a document number.
2. The launchpad collects all target mappings available to the user through the catalogs in the user's roles.
3. The launchpad filters those target mappings by semantic object, action, device type and parameter rules.
4. The matching target mapping supplies the target: the application type, the app component or transaction, and the system alias.
5. The launchpad starts that target and passes the parameters.

If no target mapping survives step 3, the user gets a navigation error instead of an app. A target mapping is therefore a routing rule evaluated at runtime, not a piece of UI.

The same intent can carry different targets for different device types or roles, which is how one tile can open a full app on desktop and a simplified one on a phone. Each field in a target mapping narrows or redirects where an intent lands.

A tile is the visual entry point that stores an intent; a target mapping is the rule that resolves that intent. The two are separate objects, often defined together but sometimes in different technical catalogs. A user needs access to both — the tile through the catalogs that place it, and the target mapping through catalogs in the user's roles — for a click to open an app. One target mapping can serve many tiles and in-app links, and one tile can resolve differently per device. Tiles decide what users see; target mappings decide what actually opens.

Create or change a target mapping when:

• a custom SAPUI5 app must be launchable from the SAP Fiori Launchpad;
• an SAP GUI transaction or Web Dynpro ABAP application without a native SAP Fiori app needs a tile;
• a role should open a different app for the same intent, for example a custom app instead of the standard one; then avoid leaving several matching target mappings in the same user's roles, and test with /UI2/FLIA.

Avoid two common shortcuts:

• copying SAP-delivered target mappings into custom catalogs when referencing them would keep SAP updates flowing, because changes to the original are propagated to its references;
• using wildcard actions or open parameter rules that make resolution unpredictable.

A target mapping change is a navigation design decision and deserves the same review as a role change.

A visible tile proves that the user can see the tile, not that the intent resolves. The usual causes, in order of frequency reported by practitioners:

1. The tile's catalog is assigned, but the target mapping's catalog is missing from the user's roles.
2. The target mapping is not enabled for the user's device type, so the app works on desktop and fails on a phone.
3. Parameter rules reject the parameters the tile or link sends.
4. The system alias points to the wrong backend.
5. Launchpad caches still hold the old content after a change. On the ABAP front-end server, run report /UI2/INVALIDATE_GLOBAL_CACHES in SE38 or transaction /UI2/INVAL_CACHES; SAP reserves /UI2/INVALIDATE_CLIENT_CACHES for exceptional cases.

Run /UI2/FLIA for the affected user before editing any content, because intent analysis shows which target mappings the launchpad actually considered. Navigation failures are almost always role-assignment or rule-matching problems, not broken apps.

• Apps on SAP BTP: an app declares its navigation targets as inbounds in its app descriptor (manifest.json, under sap.app → crossNavigation → inbounds). SAP Build Work Zone uses those inbounds as the target mappings for the site.
• Content from SAP S/4HANA: the back end exposes selected roles through content exposure, and SAP Build Work Zone consumes them with the SAP S/4HANA system set up as a content provider.

The concept is identical across deployment options — intent in, application out. Only where the rule is maintained changes.