Fiori Launchpad Content: Separate Custom Catalogs, Group by Persona, Assign via PFCG Roles

Li Wei breaks down what you need to know

Nothing exposes a poorly governed Fiori rollout faster than a launchpad full of duplicate tiles, cryptic technical names, and users who can’t find the app they need. I’ve walked into post-go-live support situations where the fix wasn’t technical—it was cleaning up three years of role and catalog sprawl that should never have happened. The good news: most of this is avoidable with a few boring, low-cost rules.

The Real Story

SAP delivers a huge amount of Fiori content. That’s useful, but it also creates a trap. Teams often start by tweaking SAP-delivered catalogs directly because it feels faster. Then an upgrade overwrites those changes, or a standard catalog gets so bloated with custom target mappings that nobody knows what’s actually in use.

The core problem isn’t Fiori itself. It’s that launchpad content is often treated as an afterthought once apps work technically. Developers assign catalogs to users at the last minute. Security teams copy roles because the original role was “close enough.” Basis transports content without checking what changed. Six months later, the launchpad is a mess.

Here’s what actually works in mid-to-large S/4HANA environments: separate custom catalogs from SAP-delivered catalogs, organize groups by persona, assign content through PFCG roles, enforce naming conventions, and validate in sandbox before production transport. None of this requires extra licensing or a big project. It requires discipline.

What This Means for You

For developers and Fiori content admins: Stop modifying standard catalogs. Create custom catalogs with your own namespace—usually ZCATALOG_* or ZC_*—and add references to standard target mappings if you need SAP-delivered apps. Keep your own tiles, custom target mappings, and any app-specific parameters inside those custom catalogs. This keeps upgrades clean because SAP doesn’t touch your Z* objects.

For enterprise architects: Think about launchpad content as part of your role design, not a separate tile repository. A role should map to a business persona—AP accountant, warehouse supervisor, purchasing clerk. The catalogs and groups assigned to that role should reflect what that persona does, not which transaction codes happen to exist.

For Basis and security teams: Assign catalogs and groups through PFCG roles, not directly to users. Direct assignment might seem convenient during testing, but it creates audit headaches and breaks least-privilege. When a user changes jobs or leaves, you want one object to revoke, not a scattered list of catalog assignments.

Action Items

1. Enforce a naming convention before you build anything

This sounds trivial. It isn’t. A common approach:

If you inherit an environment with inconsistent names, do not rename objects in production without impact analysis. But at least apply the convention to all new content.

2. Group by persona, not transaction code

A purchasing clerk doesn’t think in terms of ME21N, ME22N, ME23N. They think: create purchase order, change purchase order, display purchase order. Name the group Purchasing – Buyer and put those apps together. This makes the launchpad readable and reduces the “where did my tile go” tickets.

3. Assign catalogs and groups via PFCG roles

In PFCG, use the Menu tab to add SAP Fiori Tile Catalogs and Groups. The role becomes the single point of assignment. Users get the role, the role gets the content. That gives you:

• Least-privilege access control
• Cleaner audit trails
• Easier role maintenance
• A natural place to document why a user has specific apps

4. Validate in sandbox with real users

Don’t trust a developer who says “it works in my test user.” Put the content in a sandbox or development client, assign it to three actual end users, and ask them to perform their daily tasks. Watch where they hesitate. If they can’t find an app in 10 seconds, rename the group or adjust the tile order. It’s cheaper to fix here than after transport.

Community Perspective

The original discussion on SAP Community highlights exactly these pain points. One practitioner noted that upgrades can silently revert standard catalogs, wiping out customizations if you modified them directly. Another emphasized that naming conventions matter for audits—when an auditor asks which roles grant access to a particular Fiori app, you need to answer without opening twenty catalogs manually.

I see the same pattern in my consulting work. Clients who spend one workshop on naming and persona mapping save weeks of rework later. Those who skip it end up with “role explosion”—dozens of near-duplicate roles because nobody can tell what the original role did.

Bottom Line

Fiori launchpad content organization is not glamorous, but it’s one of the few areas where a small amount of early discipline delivers measurable ROI. Separate custom from standard content, group by persona, assign through PFCG roles, enforce naming conventions, and

References

• Best Practices for SAP Fiori Roles, Catalogs and Groups- SAP Fiori Design Guidelines- SAP AI Core Documentation

References

• SAP AI Core Documentation
• Best Practices for SAP Fiori Roles, Catalogs and Groups
• SAP Fiori Design Guidelines