An Overview of Structural Authorizations

Table 1 highlights the pros and cons for the use of different types of roles and structural authorizations in different scenarios.

Figure 2

Single roles to composite roles

Single Roles: Scenarios

Single roles may have a limited number of users due to the wide authorizations they include. There can be a limited number of resources for administrative work, which requires the authorizations concept to be as simple and clear as possible. The system uses large building blocks for converting business processes/requirements into a clear, simple, and transparent general authorizations (roles) concept. Single roles require a good understanding of HR concepts and expertise in building business process oriented roles according to current and future requirements.

To build a solid authorizations concept, you need to have a very good understanding of what is required to convert the business processes into an overall authorizations concept. Begin with the company-specific business requirements and the technical implementation of the roles, so you can convert the business requirements to technical roles. This knowledge is useful when adding new functions, particularly if you want to add new functions to existing roles. Without this understanding, most users commonly build a new role whenever implementing new functions. This leads to a wide number of roles, which are almost impossible to maintain according to a pre-defined business process and an overall authorizations concept.

All solid authorizations concepts must be based on business processes, which can be broken down into sub-processes and tasks. This is especially true in large companies as it is important to be able to match the user’s authorizations with the proper business processes, sub-processes, or tasks. When you implement reference roles and derived roles, it is important to keep the amount of technical workload as small as possible.  

Since the aim is to cut down the amount of technical workload, I advise you to build reference roles and derived roles. This means that if you need to make changes to the roles, you need to change the reference roles only. The derived roles are maintained automatically with the generation of the reference role. To learn more about what you can do with single roles, refer to my article “Weigh Your Options for Implementing Overall Authorizations” which was posted to the knowledgebase in January 2010. 

Here are some best practices for using single roles.

• Build wide roles based on business processes, sub-processes, and tasks. This helps keep the number of roles as small as possible. If you don’t build wide roles, the number of roles grows.
• Define roles clearly according to implemented HR concepts
• Implement structural authorizations to restrict users’ authorizations and avoid restricting the authorizations within roles to keep the number of roles very small
• Use reference and derived roles to keep the amount of technical/administrative work as limited as possible
• Keep the naming convention as clear as possible: make a distinction between global and local roles as well as standard and context roles

Composite Roles: Scenarios 

Composite roles can have a wide number of users, and they can be highly restrictive when it comes to the authorizations required because they consist of two or more single roles, which may include a very limited amount of data. This means that business processes are broken down into very specific sub-processes and tasks. While the single roles may consist of a very limited amount of data, the composite roles can still authorize wide access, if multiple single roles are included in one composite role. The composite roles require a lot of resources for administrative work because a large number of very small building blocks/components can be used for merging roles in different ways in various scenarios to build the general authorizations concept.

If you decide to build many small roles for each specific functionality, and the users require wider authorizations, you need to build composite roles (add many single roles together) to provide proper authorizations. If you authorize each user with a very limited functionality, you’d need to have many more users to participate in the business processes. If the number of users is very limited, which means that there are fewer users to take care of all the responsibilities, the users need to be authorized with wider authorizations. Wider authorizations can mean either using composite roles, which means adding up many small single roles together, or using single roles with wide access.

Most of the time there is no clear understanding in the technical implementation of the authorizations concept, and the number of roles grows exponentially. You need to convert the business processes into a solid authorizations concept; otherwise, it is almost impossible to maintain a solid concept.   The composite roles can be a good solution if it is impossible to build solid single roles, which are built according to the business processes. In general it is advisable to use the single roles as the basis for the solid authorizations concept.

To reduce the amount of administrative work (assigning authorizations), I recommend that you group single roles into composite roles. When you build a concept by creating a multiple number of single roles, you pick up two or more single roles to build composite roles. This way you build authorizations for each user or group of users to match the requirements based on business processes. Any time authorizations are required for any user or group of users, you pick up a number of single roles to build composite roles (Figure 1).

Figure 1

Pros and cons at a glance

Two or more single roles can be grouped together to form one or more composite roles. In Figure 1, five single roles form two composite roles. The same single role can be used multiple times (if that’s required according to the business requirements) to form composite roles, and any number of single roles can be used to form specific composite roles.

The following are some best practices for using composite roles:

• Build roles that are based on business processes, sub-processes, and tasks, and define roles according to current and future HR implementation needs
• Agree on clear ways of merging single roles into composite roles to have a solid general authorizations concept
• Agree on a clear naming convention to make a distinction between single roles and composite roles
• Keep the number of roles as small as possible (the more combinations between roles, the higher the number of roles becomes)
• Agree on using single roles as widely as possible, and use composite roles only if or when required to keep the general authorizations concept as simple as possible
• Remember: whenever authorizations need to be changed for users who have been assigned composite roles, only the single roles can be maintained (composite roles can never be changed directly)

Reference Roles/Derived Roles: Scenarios 

A company consisting of multiple organizational structures (divisions, departments, locations, or anything equivalent) benefits from implementing the reference role and derived roles for restricting the users’ authorizations. Changes can be constant and therefore you must maintain a large number of roles each time a change is made, such as new transaction codes, changes to authorization objects, or changes to infotypes. I advise that you build one reference role from which other roles are derived. The only difference between the reference role and the derived roles is the organizational levels (for example, a personnel area).

Organizational levels (a function which can be used to restrict the user’s authorizations within a role such as a personnel area) need to be maintained basically only once when the derived roles are created from the reference role. Whenever changes are required, all other functions (for example, a transaction code or an infotype) can be maintained, but the organizational levels need to be kept as they were before the change was made. It would be possible to maintain the organizational levels too if it were decided to add more restrictive components in the roles concept.

Use these best practices for reference/derived roles:

• Create one reference role for each functionality, such as maintaining personnel data
• Include all authorizations required for the specific functionality in the reference role
• Assign full access in the reference role to organizational levels
• Create a derived role- using the reference role as a basis- for each organizational structure, such as a division
• Use Personnel Area (for example) as an organizational level for each derived role to make a distinction between the derived roles. As a result, the reference role and the derived roles have the same contents except for the organizational level, which is unique for each derived role.
• Change only the reference role when changes are required to all derived roles. With the generation of the reference role, the changes are copied automatically to all derived roles (which saves technical and administrative resources).
• Define new fields as company-specific organizational levels, if required by business processes (Create new, company-specific organizational levels)

Context Roles: Scenarios 

With context roles, several users need to have multiple user roles (match a role with a structural profile) simultaneously. For example, a line manager needs to maintain authorizations (one role) to his/her team (one structural profile) according to the dynamic function module (RH_GET_MANAGER_ASSIGNMENT).  At the same time, the manager needs to display authorizations (another role) for a totally different part of the organization (another structural profile). With the standard SAP solution, multiple user roles are possible only if the personnel area or other HR master data components are used for restricting the user’s authorizations (when it is not possible to match a role with a structural profile without authorizing crossing authorizations). Having two user roles with restrictions on roles and no structural authorizations assigned enables non-restricted access to Personnel Planning (PLOG). If the context solution is not implemented and the user needs to be assigned roles including authorization object PLOG, the user’s authorizations to this object cannot be restricted according to any organizational structures. This object does not include any field for restrictions on organizational structures.

Here are some best practices for context roles:

• Replace the SAP standard solution with the context solution
• Re-create all roles by replacing authorization object P_ORGIN (HR: Master Data) with P_ORGINCON (HR: Master Data with Context)
• Change authorization main switches in table T77S0 to activate the context solution and at the same time inactivate the standard solution (according to business requirements)
• Change the naming convention to make a distinction between the roles created according to the context solution and the standard solution (if they are used at the same time)
• Implement HR specific structural authorizations
• Match two or more roles with two or more structural profiles to provide users with new authorizations
• Use SAP standard Business Add-Ins to assign structural authorizations automatically (no need to assign structural authorizations to table T77UA manually)

Structural Authorizations: Scenarios 

Structural authorizations allow a company to keep the authorizations concept as simple as possible by keeping the number of roles as small as possible. They are used when a company has created organizational structures to restrict authorizations according to time dependent structures. All organizational objects (for example, an organizational unit or a position) and their relationships (such as a relationship between an organizational unit and a position) have a validity date. They are all valid from some certain date, and they are all defined as active until another date. This means that they are time dependent.

Both the managers’ and the employees’ authorizations may need to be enabled dynamically according to the SAP standard function modules to allocate the administrative resources efficiently. Structural authorizations are also used when a company wants to restrict the use of personnel planning objects according to hierarchical structures.

Some best practices for structural authorizations are:

• SAP standard function modules may need to be used for both SAP applications for employee self-services and for manager self-services users to enable authorizations dynamically. This means that only one structural profile needs to be created for managers and another structural profile for the employees. The system automatically checks the user’s (manager or employee) authorizations according to his organizational unit assignment. SAP system includes two standard function modules (one for managers and another for the employees), which enable this dynamic authorization check. In addition to using the SAP standard function modules (which are used in the structural profiles for managers/employees), the managers need to have a chief relationship (chief of a certain organizational unit).This enables efficient use of allocated resources both with creating new profiles and maintaining the existing ones.
• To enable better system performance, a general structural profile may need to be created to guarantee that general object types (required for all users) are checked only once
• Matching authorizations in personnel planning (roles) with the equivalent authorizations in structural authorizations is critical to provide required restrictions with authorizations
• A company-specific organizational structure can be created for authorizations use to enable a non-SAP standard authorization check

Preparing for Future Changes: Scenarios 

The single most important thing with the authorizations concept is to build the roles according to your real business processes and requirements. Be sure to have them as close as possible to an SAP standard solution to be better prepared for future changes. Implementation of the context solution enables better use of SAP standard solutions, and it can be implemented even if no users currently require two or more simultaneous user roles.

Implementation of the structural authorizations provides options for both restricting the personnel planning authorizations (Organizational Management, Personnel Development, Learning Solution, Training and Event Management) and general access to time-dependent functions (including all personnel planning objects).

Here are some best practices to prepare for future changes:

• Implement the context solution even if no user currently requires multiple user roles: the only requirement is that P_ORGIN is replaced with P_ORGINCON and the authorization main switches are changed
• There is no impact on authorizations if all P_ORGIN values are replaced exactly with the same values in P_ORGINCON
• With the implementation of single roles/composite roles, implement reference roles and derived roles to allocate the resources for the technical and administrative work
• The composite roles should be used only if there are no other alternatives for creating a proper authorizations concept with single roles alone
• The composite roles should not be implemented only because there is no proper understanding of building a solid authorizations concept
• The overall authorizations concept, and especially the implementation of general authorizations (roles), should always be based on real HR business processes, sub-processes, and tasks. This enables better preparation for future challenges. It is always important to decide which business processes will be covered with SAP functions and at the same time, which business processes will be covered with non-SAP functions. This provides the basis for enabling proper access with the overall authorizations concept.
• Implement structural authorizations to enable proper use of single roles and especially context roles