/UI2/INVALIDATE_GLOBAL_CACHES — Invalidate Global Launchpad Caches
/UI2/INVALIDATE_GLOBAL_CACHES invalidates server-side caches used by the SAP Fiori launchpad for all users. After transports of launchpad content, configuration changes or app deployments, users may still see old tiles or app versions; invalidating the caches forces the launchpad to rebuild them. It should be used carefully because the first loads afterwards are slower.
Invalidates the server-side caches of the Fiori launchpad so changed content, configuration or apps are read again.
Published 31 Oct 2026· 461 words
What /UI2/INVALIDATE_GLOBAL_CACHES is for
To start quickly, the launchpad caches content such as catalogs, target mappings and application information on the server and in the browser. When content changes, the caches can serve outdated information. This report clears the global server caches so the next requests read current content.
When it is used
It is used after importing launchpad content transports, after changing roles or catalogs in bulk, after app deployments together with the application index, and when troubleshooting users who see different results than expected. It is usually part of the post-transport steps for Fiori releases in a planned window.
How it is used in practice
Run the report in the front-end server, ideally outside peak hours, and inform support teams that launchpad start can be slower for a short time. Users may also need to clear browser cache. If only one user is affected, try user-level cache clearing first rather than invalidating global caches.
Fields and objects that matter
- Scope: global server caches for all users
- Timing in relation to transports and business hours
- Related client-specific cache invalidation for narrower effects
- Browser cache on the user side
- Post-transport checklist entry that records when it was run
How to prove it in the data
Before invalidation, a user sees an old tile title or a missing catalog that is already correct in the launchpad designer. After invalidation and a browser refresh, the launchpad shows the transported content. If it still does not, the content itself or the role assignment is wrong.
ECC vs S/4HANA
Relevant for ABAP front-end servers in S/4HANA on-premise and private cloud, both embedded and hub deployments. Cloud editions and SAP Build Work Zone manage caching differently, so the same symptom there needs other steps.
Common pitfalls and how they show up
Cache clearing is a tool, not a fix for wrong content.
- Running it during peak hours without warning, causing slow starts for everyone
- Repeating it when the real problem is a missing role or target mapping
- Forgetting browser caches, so users still see old content
- Not including it in post-transport steps, creating tickets after every release
- Assuming the app index is current when the real issue is an unregistered deployment
Whose problem this is
Owned by Basis or Fiori operations and scheduled with the release and transport process. The help desk should know when it was last run, because a ticket about old content right after a release is usually solved by this step rather than by changing roles.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
Source: ERPClimb — https://erpclimb.com/sap-tcodes/ui2-invalidate-global-cachesERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.