SAP provides pre-defined roles instead of having to create them from scratch.

Is it worth using them or not? Why are they often, or almost always, not used?

SAP Roles Naming Convention

Yes, SAP for each of its applications, so system or module, releases roles called SAP standards precisely.

But how can you recognize them?

SAP standard roles have a very precise naming, they are all those that start with SAP_*

What does SAP suggest?

SAP itself suggests not directly using "template" roles, i.e., standard SAP roles, but possibly using them as a reference to create your own roles in the client namespace.

The client's namespace in this case may also not be Z* or Y*, indicating all objects that are not normally SAP but are specific of the client. The important thing is that the roles do not start with SAP*

In fact, if you try to create a role that starts with SAP, the message below appears in the PFCG (Profile Generator) transaction.

Why is it better to avoid using them?

There are different reasons why it's better not to use standard SAP roles, let's see the main reasons.

During an upgrade

SAP releases new versions according to the schedule of planned upgrades. New standard roles or additions to existing standard roles may also be included in the new features.

Therefore if you use standard SAP roles as they are, changing them, during upgrades you may lose all the configurations you have made as they may be overwritten.

The roles' content

In this case there could be different situations:

• The role menu might contain many transactions. Many more compared to the ones really necessary
• The transaction redundancy in roles could be really high (with a longer time needed to manage then in the day by day)
• The authorizations, could contain many and even critical permissions

Why the above? It is certainly not because SAP cannot define roles. But rather it is because SAP defines roles by process and by configuration of roles.

If I have to define sales orders, I will often also find parts of configuration in the role menu. This could then result in authorizations to functions not normally issued to users (in some cases even critical ones).

The management of adapting them to one's own reality

It follows that SAP roles are almost always left as they are and a client set is defined. It may be much more expensive to adapt standard roles than to make them directly from scratch.

Segregation Of Duties management

Standard SAP roles do not always take into account the risk matrix defined by the client. It follows that even in this case the roles should be adapted or often completely overturned.

And if I assigned them to some user, what should I do?

One of the checks we do, in our verification activities, is just to go and check whether any user has assigned standard SAP roles. Especially for the parts related to issues during upgrades or critical authorizations.

Ideally, to remedy the situation, you should create copies of the standard roles in the name space you defined (customer name space). Then replace the standard SAP roles with copies (possibly equal in content in the case).

Beware, in some cases and for some systems these roles may be necessary. For example, for JAVA based systems. Although little used, in the case where a JAVA system uses an ABAP system as a user repository. Some users will probably have the following role:

• SAP_J2EE_ADMIN

This assigned role in the ABAP part of the systems can determine being an administrator in the JAVA part.

In this case, therefore, this role cannot be converted. Some similar situations might, for example, refer to SAP CRM systems.

In these systems, some roles are placed in configuration tables, so removing or "converting" them could generate business disruptions.