The decision to implement a combination of general authorizations (roles) and structural authorizations (structural profiles) should always be based on real business processes and needs. According to standard SAP functionality, you should implement both general authorizations and structural authorizations to enable and restrict users’ authorizations. This requires the use of organizational structures and a link between Personnel Administration (PA) master data and Personnel Development (PD).

You basically can implement general authorizations alone because you can restrict the user’s authorizations within the roles. This means you can use organizational levels, such as personnel area  as a restriction. However, if you need to restrict the authorization to organizational structures, then you need to implement structural authorizations as well. You cannot implement the structural authorizations alone, because all authorizations to HR-specific data are within roles. If you need to use the context solution, you need to implement the structural authorization as part of the overall authorizations concept.

You have different options for the use of overall authorizations, including roles (general authorizations) and structural authorizations (structural profiles). I point out the pros and cons of using each type of role for general authorizations. In addition, I explain when and where to use structural authorizations.  

Different Types of Roles

The basic principles for general authorizations are:

• Keep it as simple as possible
• Document clearly
• Build it according to business processes
• Maintain transparency
• Meet segregation of duties (SoD) and Sarbanes-Oxley Act auditing requirements
• Ease administrative work
• Ease duplication

For structural authorizations, the most important objectives are:

• Keep the concept as simple as possible
• Keep the amount of administration work as small as possible
• Prepare a concept that enables users with proper authorizations as the business processes and needs require

The decision on roles can be based on two dimensions: administrative/technical work or SoD/Sarbanes-Oxley auditing needs. For structural authorizations, you must decide between the SAP standard solution and the company-specific solution. One option with structural authorizations includes implementing structural authorizations without a context solution or automated structural authorization assignment.

 A second option includes any company-specific implementations of automatic procedures with assigning structural authorizations (Business Add-Ins [BAdIs], which can be used with the context solution). It also includes company-specific evaluation paths and function modules (dynamic check for different groups of users such as employees and managers). You can use both options at the same time. The most important thing is the efficiency of the hierarchical personnel planning structures according to the needs of different user groups (e.g., managers and employees) and requirements for keeping a small administrative/technical workload.

The next sections define the purpose and use of different types of roles, along with pros and cons for using each type. You can use any type of role in a specific situation, and none is better than the other in its own right. You can use different types of roles at the same time. You also can use single, composite, reference, and derived roles for different purposes within the same authorizations concept. The real business requirements always need to be the basis for using any type of role.

Single Role 

A single role is one you assign directly to the user. It is created for a specific business process, subprocess, or task. These roles either work alone according to the user’s responsibilities, or with other single and composite roles assigned in addition to match the user’s needs. For example, you might require a single role as a standalone role. After having specified the users, you want to provide each user with the role he gets according to his responsibilities. Create a single role, which includes all those responsibilities this specific user needs to work in the system according to his responsibilities. This user would not need any other roles.

With another user who is responsible for many different functions, you may need to build the authorizations by combining several single roles. As you build your roles according to the processes (or sub-processes), you end up building several single roles. Now that you need to provide the user with proper authorizations, you pick up all the required single roles and assign all of them to this specific user. No role alone would be enough but all of them together provide the required authorizations.

Single roles can be used in various scenarios:

• You choose to limit the number of roles, and the users are assigned wide authorizations (according to the business processes and needs)
• You want to keep the administrative workload very small (especially the assignment and maintenance of roles)
• The number of users is limited and the users have to be assigned wide authorizations
• The building blocks of the authorization concept are big (and this can be justified according to working or auditing needs)
• There is not enough expertise to build the roles concept every time a new functionality is added, a user requires more authorizations, or a new role is built. This leads to a very large number of roles, and potentially more administrative work than it would require to match the needs of the users.

Figure 1 shows an example of a single role. The list of transactions that you can start with this role appears in the Role menu section.

Figure 1

Single role and allowed functions

Composite Role 

As with single roles, you can also assign a composite role directly to the user. You create this by picking up certain functions (single roles) for a specific use according to a specific business process, sub-process, or task. These roles always include two or more single roles, but can never be maintained directly. If you need to maintain any of these authorizations, you must always maintain the underlying single roles that define the composite roles. However, you do not necessarily need to change all the single roles. You can change just the specific role that includes the data you want to change.

You can use composite roles in different scenarios including:

• When you break down basic business processes into small sub-processes/tasks (and the authorizations concept is based on these) you can build many small single roles and pick two or more for each function
• When you have a complex authorization concept that includes many users, you may find it nearly impossible to group the authorizations into single roles. In this case, you can create many small single roles and pick two or more to build composite roles for each requirement. 
• When you need to keep the building blocks small and you need to assign users to wider authorizations

With composite roles, remember to use a solid naming convention to avoid potential problems with administration work. With an inefficient naming convention, it is almost impossible to assign authorizations properly if the number of roles is very large.

Figure 2 shows an example of a composite role. The Role menu section includes all the transactions from the single roles that have been used to create this role. You can maintain the menu and delete transactions (or any other functions) that are included more than once.

Figure 2

Composite role with allowed transactions

You can also add new folders in the Role menu to clean up the menu, especially if the User menu is implemented. This means that the users who are assigned this specific role see this menu when they log on to the SAP system.

Reference Roles/Derived Roles 

Reference roles and derived roles suit organizations with many divisions, departments, locations, or any equivalent functions. The roles’ content is exactly the same, except that the organizational level (e.g., personnel area) is different in each role. The reference role includes full access to all organizational levels. The derived roles and the organizational levels are specified separately.

The reference role always contains full access to all organizational levels. To make a restriction between the derived roles, the organizational levels need to be different in each derived role. Because you create the derived roles from the reference role, the organizational levels of the reference role can never be the same as the ones for the derived roles. This means that the organizational levels are specified for each derived role separately as the organizational levels for the reference role are always defined with all levels.

The only difference between the roles can be defined by a personnel area or any equivalent function (organizational level). Creating one role as a reference role and deriving other roles from it helps save administration work for the authorization specialists because you only need to maintain the reference roles. Whenever the reference roles are maintained, the derived roles are maintained automatically with the generation of the reference role.

Some suggested ways for using reference and derived roles in different scenarios are:

• Build one basic (reference) role with exactly the same contents as all other (derived) roles
• Include full access to organizational levels for the reference role
• Derive other roles using the basic role as a reference

In each derived role, you use the same basic contents as with the reference role. You use the organizational levels, which match the exact requirements for each function (division, department, or equivalent).

To implement the role you:

• Build one reference role according to your business requirements for each function, such as administration work)
• Build two or more derived roles by using the full contents of the reference role as a basis. To create the derived role, change the organizational levels to match the need by, for example, personnel area.

If you need to make changes to the role, keep these rules in mind:

• Make functional changes only to the reference role. The changes are automatically copied to the derived roles with the profile generation of the reference role.
• You may make direct changes to the derived role only if the contents of the organizational levels require changes
• The amount of technical work drops dramatically because only the reference roles need to be maintained, and all changes are copied automatically to the derived roles

Figure 3 shows an example of a derived role. The Transaction Inheritance section specifies the role to be derived.

Figure 3

Specify the role to be derived

In the derived role, the organizational level (Personnel area = US*) has been changed to match the need for a specific role for US users (Figure 4). All other contents are the same as with the reference role.

Figure 4

Derived role specific to US

Context Roles

With context roles, users have multiple user roles — they need to have different simultaneous authorizations to two or more different parts of the organization. For example, managers need certain access (a specific role) to their teams (subordinates) and at the same time another access (another role) to another part of the organizational structure. Two or more roles need to be matched exactly with two or more structural authorization profiles. Let me explain this with an example.

Suppose a manager needs to simultaneously access his team (matching one role with one structural profile) and another part of the organizational structure with another role (matching another role with another structural profile). To accomplish this, the standard solution does not work, because it would combine the two roles with the two structural profiles. The idea is to match one role with one structural profile and another role with another structural profile. This means that the first role should not be matched with the second structural profile and the second role with the first structural profile. To accomplish this, context solution is required.

Any single, reference, or derived role can be defined as a context role. Composite roles can never be defined as context roles. Because the composite role is created by combining two or more single roles, the composite role cannot be used as a context role. In contrast, all other role types can be used for the context solution.

With the standard solution this cannot be accomplished because matching roles to structural authorizations is not possible. However, with the context solution, it is possible to match general authorizations (roles) with specific structural authorizations (structural profiles). The context solution is the only alternative for the needs of multiple user roles with SoD/Sarbanes-Oxley auditing requirements.

Here’s how to implement it:

• Naming convention: include both the name of the functionality (e.g., manager) and the structural profile (e.g., MSS) in the name (e.g., Z_MANAGER_MSS) to enable proper administration for context roles
• Match the role with a structural profile (e.g., role MANAGER with structural profile MSS) to build a context role
• To work with the context roles, build as many combinations of roles and structural profiles as necessary to match the needs of the business requirements (processes)/user needs

To use the context solution, you need to implement the following:

• Match multiple roles with multiple structural profiles and assign these roles to users according to business requirements
• Be aware of possible problems with system performance. The system needs to perform the check several times because the context solution is created by matching roles with structural profiles, so a user can potentially be assigned several structural profiles. In addition, each structural profile refers to a certain part of the organizational structure and each part of the organizational structure can include several authorization objects and their relationships, the user may end up having access to multiple organizational structures. The system needs to check them all, which causes a performance slowdown depending on how many objects it needs to check.

Figure 5 shows an example of a context role. The role (Z_TEST_CONTEXT_ROLE) has been matched with a structural profile (Z_TEST). You could match any other role with any other structural profile to provide the required authorizations.

Figure 5

Contest roles with a matched structural profile

Structural Authorizations  

Structural authorizations restrict access to personnel data in specific substructures of an organizational unit. There are two areas in which you use structural authorizations:

• For the Organizational Management, PD, and Training and Event Management components
• For more specific authorization checks (on account of the organizational structure) during the processing of master data. This is the interaction of general and structural authorizations (overall authorizations).

With structural authorizations, all authorizations for personnel planning functions (objects/level of access) need to be matched with the equivalent authorizations in structural authorization profiles. In these, the hierarchical organizational structures need to be kept valid at all times to guarantee proper authorizations. Also, in addition to using SAP standard structural authorization, you can define and implement company-specific structural authorizations to enable assigning of authorizations according to company-specific structures.

Let me highlight some uses and best practices for structural authorizations.

• Match each user’s overall authorizations according to need and verify that overall authorizations (roles/structural profiles) include the same functions (objects/level of access)
• To improve system performance, make certain that each object is checked only once. Accomplish this by either creating company-specific evaluation paths or defining wider authorizations to non-sensitive authorization object types. If this is not implemented as proposed, you experience a negative effect on the system performance.
• Include access to general structures (functions authorized to all users) in a general structural profile (assign to all users with structural authorizations) to verify that each object is checked only once
• For employee and manager self-service functionalities, use standard function modules to enable a dynamic authorization check
• Build a company-specific organizational structure to enable better implementation of structural authorizations if all needs cannot be met with the standard structural authorizations

It is possible to implement different types of general authorizations at the same time. If the context solution (for roles) is implemented, the standard solution cannot be used at the same time. Only the standard solution (with HR master data) or the context solution can be implemented. The structural authorization needs to be implemented if the context solution is used. You can implement general authorizations alone, if the user’s authorization to organizational structures does not need to be restricted.