Learn how to implement position-based authorizations in your organization. Discover the advantages and pitfalls of having position-based authorizations.
Key Concept
The SAP general authorizations assignment concept is divided into two types: the direct assignment type, in which the user ID is directly assigned to a role, and the indirect assignment type, in which the user inherits the role through the position. Although the direct assignment type is commonly used when implementing an SAP system, the indirect assignment type is becoming increasingly popular with companies that have a strong focus on HR and rely on the position-based segregation of duties.
A position-based authorization approach (also called indirect assignment) is predicated on the fact that positions stay with companies, while employees may not. Therefore, by basing a job on the position rather than on the employee, companies can reduce maintenance and ensure that their security needs are met.
Overview of the Functionality
In the SAP environment, users require appropriate authorizations to perform their tasks. A security administrator can assign the roles required directly by using transactions SU01, SU10, and PFCG. However, if an employee leaves the organization and is replaced, the assignment of the role to the user ID must be done again.
There are two ways to avoid having to re-do this assignment. The first method is to attach the user ID of the former employee to the new hire along with the role (i.e., direct assignment). The second method is the indirect role assignment or position-based authorization, in which the role is assigned to the position — not the user. This second method saves a lot of time and effort because, as the role is position based, it does not need to be reassigned every time a new employee takes the position.
Because Organizational Management (OM) object data is the backbone of the position-based authorization approach, inheritance plays a major role. Common roles can be attached to organizational units, jobs, functional areas (in enhancement package 4), and job families (enhancement package 4), which ultimately are cascaded down to individual positions via evaluation paths. A classic example of this is the employee self-service role (back end). This role is generally assigned to all employees and, hence, can be attached to the root organizational unit of the current organizational structure. You can then modify the standard evaluation path for this requirement.
Inheritance and the use of evaluation paths add a lot of flexibility to this functionality. Custom OM objects can also be used in standard evaluation paths to cascade roles to the position and then to the user. This is supported with a configuration for defining custom object relationships with roles.
System Prerequisites
Before going into further detail, you must ensure that you have the following system prerequisites. They are:
- A valid user ID should be maintained in infotype 0105 with subtype 0001 for all employees. This user is the ultimate recipient of the indirect assignment of the role.
- Evaluation path US_ACTGR should be available and adjusted according to business needs.
- The HR_ORG_ACTIVE switch should be set to YES in table PRGN_CUST. This is done so that whatever changes (e.g., additions, deletions, or other changes) are made in the HR organizational model for objects, the relationships that are linked to that role can be replicated for that user. Use SAP standard report RHAUTUPD_NEW (transaction code PFUD) to accomplish this.
- The Organization Management button (or menu option) on the User tab in transaction code PFCG should be activated. You accomplish this by following menu path Go to > Setting > Complete View on the main screen. This option helps security administrators assign roles to HR objects (organizational unit, job, functional area, and job family) from the role maintenance interface (transaction code PFCG) itself, without using OM modes (e.g., simple maintenance mode [transaction code PPOM_OLD] or expert mode [transaction code PP01]).
Note
Subtype 0001 is the standard configuration setting for infotype P0105, which contains the SAP user name. However, although this is the most common configuration, it is not the only configuration. To determine which P0105 subtype contains the SAP user name, use function RH_GET_HR_USER_SUBTY.
Instructions for Implementing Position-Based Authorizations
Here are the steps you need to take to implement position-based authorizations. In this case, I am assuming that the user’s ID is attached to the employee through infotype 0105 with subtype 0001.
Adjustment of Evaluation Path US_ACTGR
Evaluation path US_ACTGR is used as the SAP system’s standard route to find the indirect role assignment recipient (user ID) though the OM hierarchy. Report RHAUTUPD_NEW (transaction code PFUD) feeds roles entered in the report as selection criteria to the evaluation path as the starting agent. The report finds recipients in the form of the user ID to whom this role should be assigned (Figure 1). After identification of the recipient, it also assigns that role to the intended user ID.

Figure 1
Indirect role assignment process flow
Table 1 illustrates what the evaluation paths look like in the standard SAP system.

Table 1
Standard evaluation path US_ACTGR
This table is taken from the SAP standard table for evaluation paths (transaction code OOAW). For the reader’s convenience, I have changed the names of column headings to clarify the meaning. To adjust these evaluation paths, it is important that you have a detailed understanding of these evaluation paths.
Example 1
In my first illustration of how to implement a position-based authorization, I am using an example in which the role (Z_HR_TALENT_SPECIALIST) is attached to a job (object C); positions (object S) are assigned to jobs; employees (object P) are assigned to positions; and the users (IDs) are assigned to employees in infotype 0105 with subtype 0001.
Running report RHAUTUPD_NEW with the role selection criteria as Z_HR_TALENT_SPECIALIST has the following results:
Step 1. Sequence number 20 in Table 1 is going to use Z_HR_TALENT_SPECIALIST as its starting point and find all the jobs to which this role is attached in HRP1001 through relationship A007.
Step 2. All the jobs from step 1 are passed to sequence number 80 to find all the positions attached to them through relationship A007.
Step 3. Positions from step 2 are passed to sequence number 110 to find any object attached to them through relationship A008. The output could be the user or person or some other term. In my example it is person.
Step 4. These employees (IDs) from step 3 are passed to sequence number 70 to find the user ID attached to them through relationship B208* in infotype 0105 with subtype 0001.
Step 5. The user ID from step 4 is passed on to report RHAUTUPD_NEW to attach the Z_HR_TALENT_SPECIALIST role to this user ID.
Note
Relationship B208 is a special relationship between the employee and the user ID, which upon detection instructs the system to determine the user ID for an employee though infotype 0105 with subtype 0001. As illustrated above, it is clear that if this example is the actual business case, evaluation path US_ACTGR in Table 1 can be reduced to only sequence numbers 20, 80, 110, and 70 and it works well.
Example 2
Companies often have a single common role for all their employees in the organization, which allows employees limited permission for updating their personal information or to request additional rights. This can pose problems. For example, when many new employees are hired on a single day, the recruitment team may not have time to send the data for the new hires to the security team. Then, when these employees are asked to update their information on the system — to update their bank or address details, for example — they don’t have enough rights in the system to allow them to update their personal information.
Companies often create new applications in their SAP systems to deal with this kind of situation — workflows, for example, to allow employees to request additional system rights — but if the employee does not have basic rights to the system or access to the system, they are unable to update their information. One way companies can avoid this problem is to allow new employees access to the employee self-service system from the first day they are hired. If the company has a self-service application that allows for employees to request additional rights, this should be part of the employee self-service role.
Allowing basic rights in the system to new employees (on any given day) can be achieved using the indirect assignment approach. This can be done by attaching a role to the top organization unit of the organization structure. Then, a new employee joining or moving anywhere in the structure inherits that role as soon as the employee is attached to a position (Figure 2). This assumes that the employee has a valid user attached in infotype 0105 with subtype 0001.

Figure 2
Indirect assignment approach when the role is assigned to top organizational unit
Assuming that organizational unit O1 is attached to the employee self-service role Z_HR_EMPLOYEE_SELF_SERVICE (Figure 2), then the evaluation path US_ACTGR has to be adjusted as shown in Table 2. Note that this evaluation path needs to be adjusted for every custom scenario, so that assignment of the role can be done correctly for the desired recipients.

Table 2
Adjusted evaluation path US_ACTGR
The rows highlighted in Table 2 are going to be used by report RHAUTUPD_NEW to identify employees who are going to have the Z_HR_EMPLOYEE_SELF_SERVICE role assigned to their user IDs. The only difference between the standard (Table 1) and custom (Table 2) evaluation paths is sequence number 90, which has been added in the customized version of US_ACTGR to accommodate the business scenario. The route followed in the custom evaluation path is circled in Table 2.
After report RHAUTUPD_NEW runs with Z_HR_EMPLOYEE_SELF_SERVICE as its selection filter, all employees or users attached to positions S1 through S10 receive this role. This is because report RHAUTUPD_NEW executes evaluation path US_ACTGR in sequences 30, 90, 100, 110, and 70.
Example 3
In this illustration, I show how you can use other objects (i.e., not work center, job, position, organization unit, user, and person) used by the SAP system as standard objects to link to the role(s) for indirect role assignment.
This example is also based on the needs of an organization. For instance, functional area (enhancement package 4; object FN) is used as the starting point for segregation of duties across the enterprise. There can also be a need, when the custom OM object is a point of start, to decide the right a user is going to have in the SAP system. These scenarios require a little more configuration than shown above. The diagram in Figure 3 shows a new job hierarchy (available only with enhancement package 4) and possible ways to adjust the evaluation path.

Figure 3
Indirect assignment approach (when a role is assigned to a functional area)
Note that functional areas, job families, and jobs are not shown in the organizational structure, but their relationships need to be shown in the evaluation path so that report RHAUTUPD_NEW can pick this hierarchy to find the position or employees to whom it should assign the role. Before adjusting the evaluation path, you need to do some quick configuration in transaction code OOVK for relationship 007. Add relationships between the functional area (object FN) and the role (object AG) under the Allowed Relationships folder for relationship 007, as shown in Table 3.

Table 3
Defining new relationships between functional areas and roles
Also, add an entry for object FN (Functional Area) in Time Constraints folder as shown in Table 4.

Table 4
Defining time constraints for functional area and relationship B007
Now adjust the evaluation path as shown in Table 5. The difference between the standard (Table 1) and customized (Table 5) evaluation paths is the addition of sequence numbers 25, 74, and 78.

Table 5
Adjusted evaluation path US_ACTGR
If the Z_HR_HUMAN_RESOURCES_DEPT role is assigned to a functional area FN1 (Figure3) and after report RHAUTUPD_NEW runs with Z_HR_HUMAN_RESOURCES_DEPT as a selection filter, all the employees (users) attached to positions S1 to S6 receive this role. This is because report RHAUTUPD_NEW executes evaluation path US_ACTGR in sequences 25, 74, 78, 80, 110, and 70. This process can also be followed for using custom OM objects in indirect assignment.
Assigning roles to OM objects (organization unit, position, job, functional area [enhancement package 4], and custom OM objects) can be done two ways:
1. Transaction code PFCG (used mostly by security administrators)
2. Transaction code OM (PP01; used mostly by OM practitioners).
Whichever way it is done, this assignment is nothing more than a creation of a relationship (007) between the role object (AG) and other OM objects, such as organization unit (O), job (C), and position (S). Therefore, the evaluation path US_ACTGR and the RHAUTUPD_NEW report can only act once active relationships are defined between the role and other OM objects.
Assigning Roles Using Transaction Code PFCG
Here is how you assign roles using transaction code PFCG. First, as mentioned previously in the prerequisites, you must activate the Organizational Management button (or menu option) on the user’s tab in transaction code PFCG. Do this by clicking the Complete view (Organizational Management and workflow) radio button on the screen shown in Figure 4. If this is not done, the Organizational Management button is not shown and this menu option is disabled.

Figure 4
Organizational management and workflow selection screen
Enter the role maintenance interface with change mode, open the user tab, and click the Organization Mg… button (Figure 5). Alternatively, you can also click the menu option Goto > Organization management as soon as you enter the role maintenance interface in transaction code PFCG (Figure 6).

Figure 5
Accessing role maintenance interface option 1

Figure 6
Accessing role maintenance interface option 2
Click the possible agents icon (circled in Figure 7) to select the SAP standard objects, so that the concerned role can be assigned to this object (Figure 7). The relationship between the object selected and the role is created in table HRP1001. All other objects (other than the ones shown in Figure 7) have to be maintained through transaction code PP01.

Figure 7
SAP standard objects selection screen for role assignment
User reconciliation is also possible through this screen by selecting the circled icon in Figure 8.

Figure 8
Options for user reconciliation
Assigning Roles Using Transaction Code PP01
To assign a role using transaction code PP01, select the object type, concerned object ID, and relationship infotype, and click the create icon. You create the relationship with the OM object as shown in Figure 9.

Figure 9
Standard PP01 screen for assignment of roles to OM objects
User reconciliation is not possible through this screen in this case and can only be done through report RHAUTUPD_NEW (transaction code PFUD).
User Master Comparison
User master comparison is best understood by breaking it down to the following subtasks:
- Identifying recipients of the selected role assignment through evaluation path US_ACTGR
- Assigning roles to the recipient users identified
- Ensuring that any changes (delimiting, additions, or deletions) to the objects or to their relationships with role(s) (object AG) are mirrored to the concerned user
- Adjusting the user profile
As already mentioned, report RHAUTUPD_NEW (transaction code PFUD) performs a user master comparison for indirect role assignment. Initial user reconciliation can be done via transaction code PFCG while assigning role(s) to OM objects. However, any changes to existing assignments can be done by this report automatically. This can be achieved by scheduling the report to run every day or twice a day (especially for days when new employees commonly join the company)
Implementation Considerations
Here is a list of the eight most important things to take into consideration when doing an implementation.
- Businesses need to accept and adapt to the fact that position means a set of responsibilities> Hence multiple users can be assigned to a position (if needed), but cannot have different sets of tasks and responsibilities. If the company needs different roles and different responsibilities to be assigned to a position for a clear-cut segregation of duties, then the organization should assign different positions to each of the users.
- Processes should be defined to allow employees to raise requests for additional roles and responsibilities coupled with an approval workflow. Automation of this process (whether in the SAP system or in another system interfaced with the SAP system) should ultimately lead to adding new roles (responsibilities) to employees’ positions.
- Processes should be defined to add roles to positions when creating the position. Also, if possible, provisions should be made for suggesting roles to be attached by the person requesting the new position.
- Processes should be defined keeping in mind the possibility of transfers or promotions (i.e., changes of position). With indirect assignment, everything that affects an employee’s position should be looked at again.
- Responsibilities or tasks associated with each role should be documented comprehensively in laymen’s terms (most likely in the job description) and published to the central repository for the entire organization. This facilitates all levels of employees to understand their own and the next level of responsibilities. It also helps employees to avoid requesting incorrect roles for themselves or employees who are junior to them.
- Assign roles with names that have descriptive and known naming conventions. This helps business users’ understanding and avoids any potential mismatches during system troubleshooting by allowing them to check roles at a glance.
- If employees are not on the permanent rolls of the company, assign them to positions so that they are also covered under the indirect role assignment approach.
-
Implementation partners have to cleverly mould the mindset of the business to use OM objects for role assignment. Benefits of the approach should be illustrated to HR practitioners on day 1 of the discussion. Then, acceptance can be leveraged to get this approach accepted in a wider forum with representatives from other business functions.
Advantages of the Indirect Assignment Approach
There are three major advantages to using position-based assignments. They are:
- Less maintenance. With indirect role assignment, the user tends to get specific rights as soon as they occupy a position. With this approach, vacant positions can be re-used for new or replacement employees without modifying the rights they have to have to access the system.
- Increased flexibility. You have the ability to tweak the flow of authorization rights to users from any level of the organizational structure or even outside of it (Figure 3). This is possible because evaluation path US_ACTGR can be adjusted to derive roles for the user, which helps businesses avoid any potential loss of work because of lack of authorizations. It also alleviates chaos and confusion in the employee’s initial days, as they have enough position- or job-specific rights.
-
Segregation of duties. Unlike with the direct assignment approach, where users are directly assigned authorization roles, the indirect assignment of roles allows organizations to model the segregation of duties concept (i.e., where employees get authorizations based on the duties they have to perform). Position, job, and other OM objects can define the relevant responsibilities in terms of roles assigned.
Disadvantages of the Indirect Assignment Approach
Potential disadvantages to using the position-based assignment approach include:
- Cumbersome maintenance in certain instances. With this approach, maintenance can be cumbersome when context-specific structural authorizations are also active along with general authorizations.
- Limited role assignment. Using transaction code PFCG, roles cannot be assigned to objects other than organizational unit, position, job, work center, person, and user. Instead, transaction code PP01 is used to create these assignments. Transaction code PP01 is more commonly used by OM practitioners, and therefore this limitation can create problems when it comes to sharing the responsibilities of creating these assignments.
- Completing remaining tasks. If employees need to complete an old task (related to an old position) after a position change, the indirect assignment approach can be problematic because employees tend to receive new rights (and old rights are removed) as soon as they are assigned to new positions. This change in rights could make it impossible to complete old tasks.
Prashant Rastogi
Prashant Rastogi works at Accenture as an SAP HCM associate manager. He has been working in SAP ERP HCM for the past seven years in various assignments. Prashant has experience in implementing ESS, MSS, SAP ECM, Performance Management, Succession Planning, Talent Management, OM, PA, and Nakisa. Prashant has an MBA (HR) along with a master’s in law and labor welfare. He is also an engineer in IT.
You may contact the author at prashant.rastogi@accenture.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.