Intent-Based Navigation

In the SAP Fiori Launchpad, the part of the URL after # is an intent, not an application address. A typical intent looks like #PurchaseOrder-display?PurchaseOrder=4500000123.

1. The user clicks a tile or a link, or an app triggers navigation in code. Each of them names only the semantic object, the action and optional parameters.
2. The launchpad checks which intents the user may use. On the ABAP launchpad, these come from the catalogs in the user's PFCG roles.
3. The launchpad's target resolution compares the intent with the available target mappings, including device type and parameter rules.
4. The winning target mapping supplies the application: a SAPUI5 component, an SAP GUI for HTML transaction, a Web Dynpro ABAP application or a URL, plus the system it runs against.
5. The launchpad starts the target and passes the parameters.

The calling side never learns which app answered. Intent-based navigation is a late-binding contract between what the user wants to do and the app that does it.

The indirection solves real life-cycle problems:

• Role-specific targets. The same intent can open a manager view for one role and a clerk view for another, through configuration only.
• Device-specific targets. A desktop user and a phone user can reach different apps through the same link.
• Replaceable apps. An intent can point to a Web Dynpro ABAP application today and to a new SAPUI5 app later, without changing the apps that link to it.
• Independent deployment. Apps have different life cycles; a source app cannot assume a target app is installed. Intents let the launchpad decide what exists for this user, in this system.
• Extension without modification. Customers can redirect a standard intent to a custom app without touching SAP code.

These properties are why SAP Fiori apps link to each other through intents rather than hard-coded addresses. Intent-based navigation trades a little configuration effort for apps that can evolve independently.

• SAP Fiori elements: fields annotated with a semantic object become smart links, and outbound navigation is declared through annotations and the app descriptor. The framework calls the launchpad on the developer's behalf.
• App descriptor: sap.app → crossNavigation declares inbounds (the intents an app accepts, with parameter rules such as how additional parameters are handled: allowed, ignored or not allowed) and outbounds (the intents an app may trigger).
• Freestyle SAPUI5: the shell service sap.ushell.services.Navigation offers asynchronous methods to navigate, build a link, check whether an intent is supported for the user and list the links for a semantic object. The older CrossApplicationNavigation service is deprecated since SAPUI5 1.120.

Developers should check that an intent is supported before rendering a link, because support differs per user. Intent-based navigation in code is a request to the launchpad, never a direct call to another app.

• It needs a launchpad or site runtime. Intents are resolved by the shell. SAP describes the Navigation service as working within the scope of the current launchpad, so an app opened on its own, outside the launchpad or an SAP Build Work Zone site, has no service to resolve them.
• Errors appear at runtime. A missing target mapping or wrong role surfaces when a user clicks, not when content is transported, so testing per role matters.
• Parameters travel in the URL. Large selections need an app state instead of URL parameters, and sensitive values should not be placed in an intent.
• Cross-system targets depend on configuration. A target in another system relies on a correct system alias or destination.
• Navigation is not process state. An intent opens an app with context; it does not record what the user then does, whether a task is complete or what comes next.

These limits follow from the design: intent-based navigation resolves where to go, and leaves what happens there to the target app.

On the ABAP launchpad, follow the evidence rather than editing content first:

1. Read the intent from the browser address bar or the console message.
2. If the console shows an application log ID, open the UI2 application log in SLG1; from the message, you can jump to intent analysis.
3. Run /UI2/FLIA with the intent, the device type and the affected user. It shows which roles and catalogs carry the intent and which target mapping belongs to it.
4. If the target mapping is correct but the app loads in the wrong system, check system aliases with /UI2/FSAC.
5. If a SAPUI5 component cannot be loaded, check the SAPUI5 application index log with /UI5/APP_INDEX_CALCULATE.

On SAP BTP, compare the tile's intent with the inbounds of the deployed app descriptor. A failed intent is usually a content or role problem, and intent-based navigation tooling shows which one before anything is changed.

The syntax and the idea are the same; only the source of target mappings changes. Apps deployed on SAP BTP declare their inbounds in the app descriptor, and SAP Build Work Zone treats those inbounds as the targets for the site. Apps from SAP S/4HANA reach a Work Zone site through the Federation of Remote Content Providers, which exposes the backend launchpad content to the site. Across deployment options, intent-based navigation keeps the same contract: an intent goes in, and the user's content decides which app comes out.