Building Display Roles The Smart Way In SAP S/4HANA

Why display roles matter

In many SAP S/4HANA implementations, one of the under-appreciated tasks is defining roles that only allow viewing of data and functions, the so-called “display” roles. Why does this matter? Because letting users see without the risk of accidental change or authorization excess is key for audit and compliance purposes as well as for smooth operations. In this post I’ll walk through why display roles are important, what you should watch out for, how to build them, and some real-life tips to avoid common pitfalls.

Understanding users needs

The first step is to understand exactly what the user needs to see – which reports, apps, and organizational levels. Once that’s clear, you can start designing the role. In an on-premise S/4HANAsystem, transaction PFCG allows you to copy a standard role, remove change activities (e.g., ACTVT 01/Create, 02/Change, 06/Delete), and leave only 03 – Display. These are just examples, always review which activities are relevant for your specific use case.

Fiori considerations

For Fiori, check catalogs and apps carefully – some “read-only” apps can still allow edits. Negative testing is crucial: assign the role to a test user, navigate through the Fiori Launchpad, and verify that nothing can be modified accidentally.

Real-Life example

A real-life example makes this clearer: in one project, the Quality Assurance team needed access to inspection data but no ability to change batches or goods movements. By copying the standard Quality Manager role, removing all change transactions, and restricting access to relevant plants, the team created a safe and effective Z_QA_DISPLAY role. Post go-live, no accidental changes occurred – a small effort with a big impact, showing how careful design and testing can pay off.

Documentation & useful tools

Following this kind of example, naming and documentation become even more important. A clear name such as Z_DISPLAY_FINANCE_ALL instantly tells everyone that it’s a view-only role. Keeping documentation tidy reduces mistakes, simplifies audits, and makes future maintenance easier.

SUIM – analyze user assignments, transactions, and authorizations.
Fiori Apps Library – see which apps are delivered, with their catalogs and roles.
Role Comparison in PFCG – compare standard vs custom roles to track changes.
SAP Authorization Logging – monitor any attempted changes to ensure read-only roles are effective.

Final checks

Display roles are about trust and control. Done right, they let users see what they need, keep your system secure, and make audits easier. Take a moment to review your display roles: when was the last time you checked them?

Also, don’t forget to review access on the user level, sometimes a user can still get 01, 02, or other change activities through another role. Catching such cross-pollination early helps maintain true “display-only” access.

FAQs

A display role allows users to view data and reports without the ability to create, change, or delete information. It helps prevent accidental changes and supports audit and compliance requirements.

In on-premise systems, a standard role is copied in PFCG and change activities like ACTVT 01, 02, and 06 are removed, leaving only ACTVT 03 (Display). The role is then tested to confirm read-only access.

No. Some Fiori apps marked as “display” can still allow changes. Negative testing in the Fiori Launchpad is required to confirm that no modifications are possible.