Permission roles derivation (inheritance)

Continuing with SAP alphabet. Hope we both understand that there are template roles and functional and they differ.
First ones are never assigned to end users and in fact are templates for functional roles. We use them to quickly edit function in one place and derive changes to functional. Functional roles are already typed with exact permissions for personnel areas, employee groups and subgroups, business units and other objects.

If you don’t want to die creating all combinatoric variety of functional roles per each personnel area and employee group, you can use derivation tool. When deriving we define master role (template) with a nice user menu, setup authorization objects with organizational levels. Then with easy we create derived role which references to master role. Derived role inherits menu and all authorization objects from the master role. When we do any change in master role it reflects in slave roles. Also we can do any changes in slave roles without any effect to master. You only can’t change user menu in slave role.

In pictures it looks like this.

Create master role

Read More


Organisational Levels – Simplify SAP Permission roles management

How to maintain a huge number of permission roles in SAP?

Have you ever maintained a huge number of permission roles in SAP systems? It’s a nightmare when you need to change dozens of roles to run a new personnel area or a plant. Clever boys in SAP have provided two really working solutions to us. Permission roles inheritance and organizational levels. The first one is explained in details here, while the second part is below for your convenience.

Solution – Organizational Levels

Organisational levels are variables which could be filled centrally instead of filling up in each permission object manually. The organizational level is created in PFCG_ORGFIELD_CREATE report. Run it, fill with technical field name (like PERSK) you want to make available as org. level. If you made a mistake, run PFCG_ORGFIELD_DELETE report to delete. So you create an organizational level for PERSK field in the P_ORGIN object and can set it up within one window. It’s very convenient in HCM where you could have several P_ORGIN objects within a single role.

Change role and authorization in PFCG transaction

Change role and authorization in PFCG transaction

Read More


Automatic PFCG roles assignment

There is a magic tool in the system that allows you to assign PFCG roles based on organization position. It means we can use org chart to say what roles and structure profiles to assign to users who holds that position. Let’s say for HR department we can assign role “HR Manager” and ALL structure profile. WHen somebody moves to HR department system will automatically assign that role and profile to him. The same if somebody leaves HR department role and profile will be revoked. There is no need to call IT to grant/revoke access. This is old mechanism, not very flexible, bo SOD control, but it works. New solution is SAP GRC.

Read More


ArchiveLink permissions

Did you know that ArchiveLink could work with HCM authorizations and P_ORGIN permission object? Citate: “With correct set system documents could be attached to any infotype and access to them will be granted by infotype authorizations. Thus if you attach scans to infotype 21 only users with access to 21st infotype will see them”. (?) WHITE PAPER SAP Employee File Management. So, ArchilvLink permissions could use regular SAP permission role objects without any additional customization which is great!

I’ve never used this trick cause all documents were assigned to personnel number and 2 infotype. Nice and free solution.

White paper – An Introduction to SAP Employee File Management-1