SAP Introduction

Fiori is both a design system (principles: role-based, responsive, coherent, simple, delightful) and a large library of apps delivered through the Fiori launchpad. Built on SAPUI5 web technology, Fiori apps run in a browser on any device and are organised around user roles and tasks rather than the old transaction menu.

• Transactional: perform business tasks (create/change objects).
• Analytical: show real-time KPIs and insights (on HANA).
• Fact sheet: display an object and its related data with drill-down.

This is the part that confuses newcomers, and it is a chain of four objects. Getting it wrong is why an app exists and nobody can see it.

The app itself is a UI5 application talking to an OData service. The service must be activated in the back end or the app has a front end and no data.

A catalog groups apps and is what makes them available to a role. A group decides how tiles are arranged on the launchpad for the user who has them. Catalogs control access, groups control presentation, and confusing the two is the most common Fiori configuration mistake.

A business role ties catalogs and groups to actual users through the authorisation model. If a user cannot see an app, walk that chain backwards: is the service active, is the app in a catalog, is the catalog on their role, is the group assigned.

The app library is the reference that tells you, for any standard app, which OData services and back-end roles it needs. Reading it before configuring saves guessing.

Half an hour on a system with Fiori configured, and it teaches the chain above by walking it.

1. Log into the launchpad and note which tiles you have.
2. Find a standard app in the app library and note its OData service and its back-end and front-end role requirements.
3. Check the service is active. If it is not, the app will load and show an error rather than nothing, which is a useful distinction when diagnosing.
4. Add the app's catalog to a test role, and add its group. Assign the role to a test user.
5. Log in as that user. The tile is there. Remove the group but keep the catalog and log in again: the app is still reachable by search, but the tile has gone. That difference is the whole catalog-versus-group distinction in one action.

Fiori dramatically improves usability and adoption over SAP GUI, and in S/4HANA many capabilities are delivered as Fiori apps. Understanding the launchpad, roles/catalogs and the OData backend connection is essential for users, functional consultants and developers alike.

There is a practical reason beyond usability. Fiori apps are role-based, so a user sees the tasks for their job rather than a menu of everything. That changes how authorisation and training are approached: instead of teaching transaction codes, you assign a role and the relevant work appears. See Fiori catalogs for that structure in detail.

• Embedded or hub deployment. Embedded is simpler and ties the front end to the back end's lifecycle. A hub serves several back ends and adds a component to run and upgrade. See Fiori deployment.
• Which apps, and for whom. Rolling out every available app produces a cluttered launchpad nobody trusts. Starting with the handful each role uses daily works better.
• Standard or extended. Extending an app is supported and it is code you maintain. Adapting the standard through configuration first is the cheaper instinct.
• What stays in SAP GUI. Configuration and long-tail transactions still live there, and pretending otherwise sets an expectation the project cannot meet.

• Who owns the launchpad. Tiles, groups and catalogs drift as roles change, and without an owner the launchpad slowly fills with apps nobody uses and loses the ones people need.

A common support call, and the causes are few enough to work through quickly.

Dynamic tiles show a count or a value, and that number comes from an OData service call separate from the app behind it. So a tile can be wrong while the app is right, and the two are diagnosed differently.

Caching. Tiles refresh on an interval defined in their configuration. A number that is stale rather than wrong is usually this, and it is configuration rather than a fault.

Authorisation. The tile counts what the user is allowed to see. Two users legitimately see different numbers on the same tile, which surprises people until it is explained.

The wrong service or filter. Custom tiles are often pointed at a service with parameters that drifted from what the business meant.

Client-side caching in the launchpad. The browser holds a good deal, and clearing the cache resolves a surprising share of "it is not updating" reports.

The order to check: reproduce as the affected user, compare against the app itself, then look at the tile's service and its refresh interval. Working from the number backwards to the service is faster than starting with configuration.

The expectation that Fiori replaces SAP GUI causes more disappointment than any other Fiori question, so it is worth setting straight.

Fiori covers the tasks people do repeatedly: creating and approving documents, monitoring, and the analytical overviews built on them. That is most of what an end user does, and it is the right target for a rollout.

SAP GUI keeps the rest. Configuration lives in the IMG and is not being replaced. Long-tail transactions, technical work, and much of what a consultant does daily remain there. Some GUI transactions are also reachable inside the launchpad, so a user can be given one without leaving the Fiori shell, which is a useful middle ground.

The practical planning consequence: a rollout should say which roles move fully to Fiori, which work in both, and which stay in GUI. Promising an organisation that GUI is going away sets up a failure that has nothing to do with the technology.

• Expecting Fiori to replace all GUI, config and long-tail transactions remain in GUI.
• Ignoring the role model that controls which apps appear.
• Treating Fiori as only cosmetic, it changes how users work.

• Blaming the app when the OData service is not active. Check the service first.
• Confusing catalog and group. One grants access, the other arranges tiles, and the symptoms differ.
• Building custom apps before checking the library. See Fiori development for when building is genuinely the answer.

• Rolling out every available app at once. A launchpad with two hundred tiles is not more capable than one with twelve; it is less usable, and users stop trusting it.

• Custom apps built before the standard one was tried. The library is large, and an app that nearly fits plus a configuration change is cheaper to own than a bespoke one that fits exactly today.
• Ignoring mobile. Fiori is responsive by design, and approvals in particular are used on phones far more than projects anticipate.

Finding an app is the easy half, and configuring catalogs, groups and roles so the right people see the right tiles is the part you do in the course.

If one thing is worth remembering: when an app does not appear, walk the chain backwards. Service active, app in a catalog, catalog on the role, role on the user, group assigned. Five checks in order, and they resolve almost every access question without opening configuration.