Do you want to assign authorizations in HR that still work when a department grows or structures in the company change? Structural authorizations can be the tool of choice here – if your employees only have a single function in an area of responsibility. Here we explain what you need to pay attention to and how structural authorizations work.
Let’s assume you work for a medium-sized company. The structures are comparatively simple, but the company is growing continuously and the company organization is therefore changing all the time. You can’t get anywhere with general authorizations, because they always have to be maintained manually when the structure of departments or teams changes. You opt for structural authorizations.
However, these are not only used in personnel administration, but also for:
- Displaying and maintaining organizational management objects
- Displaying and maintaining all HCM objects created from HRP tables
Important: Structural authorizations only work in conjunction with general authorizations. To grant authorizations, the check in structural and general authorizations must be positive.
To use structural authorizations, you must create structural profiles (transaction OOSP).
Profiles are – like roles – first created user-independently and then assigned to the users. Make sure to assign unique names for your own profiles if possible.
Double-click on the profile (note that the line must be selected!) to open the profile’s maintenance parameters and to define the profile:
- Plan version
- Object type (usually internal HCM objects, such as P (person) or AP (applicant))
- Object ID (identifies the root object)
- Maintenance (allows maintenance of the object if this is defined in table T77FC and maintenance is also allowed via the general authorizations)
- Evaluation path
- Status vector (1 = active, 2 = planned, 3 = requested, 4 = approved, 5 = rejected)
- Depth (number of authorized levels below the root object, 0 or blank includes all levels)
- Sign (reverses the direction for depth, so the number of authorized levels is no longer counted down from the root object, but up from the last level to the root object)
- Period (determines whether the user must be authorized directly on the key date or only in a period (such as month or year) around the key date: D = key date, M = current month, Y = current year, P = past, F = future).
- Function module
To define the authorizations that are assigned via a structural profile, the most important fields are the evaluation path and the object ID or the function module.
Evaluation paths determine the authorization check
Structural authorizations follow predefined evaluation paths, for example the O-O-S path. O stands for organizational units such as departments or teams, S are the positions in the company. Alternatively, the path can also be O-S-P, for example, in which case the people who occupy these positions are also included in addition to the positions. Each organizational unit, position and person is an object with its own object ID.
Depending on what you want to authorize, select one of the objects as the root object for your evaluation path. You enter the ID of the root object in the structural profile. All other objects that follow under the root object within the evaluation path are automatically authorized as well.
Example: In your company, there is Sales as a department and 5 teams within it. You now want to create an authorization profile with which the head of department can see the organizational assignment (infotype 0001) of all sales employees. Furthermore, you need a profile with which the team leaders can view the salary data of the employees. However, this should only be possible for their own team.
You decide to use the evaluation path O-O-S. For the department manager profile, the Sales department (O1) becomes the root object. This means that all teams and positions below the department (gray fields) are authorized:
For the team leader profile, the teams (O2 – O5) become root objects and the positions below are also authorized (gray fields for team 2 as an example):
The problem: here you need to create a separate profile for each team leader, because each of them need a different root object for their authorizations. Depending on how large your company is and how far you have to differentiate the authorizations, this can lead to an unmanageable number of profiles.
Use function blocks instead of object ID
To avoid this, you can work with function modules – instead of the individual object ID. Function modules read the position of a user within the organizational structure and thus dynamically determine the required root object. But beware: This only works if you have a really seamlessly maintained org management!
You can program your own function modules or use the standards that SAP already provides.
In our example of sales team leaders, for example, the standard function module RH_GET_MANAGER_ASSIGNMENT works. So you just create an authorization profile for all team leaders and enter the function module instead of the object ID of a root object. The function module now reads out which position is occupied by the user to whom the profile is assigned and to which organizational unit in the company this position is assigned as manager. (Important: If you have not maintained the position assignment properly, i.e. the team leaders do not appear as leaders in Org Management, the function module will not work). The function module automatically uses the organizational unit as a root object and checks the authorizations along the stored evaluation path. In this way, you only need one profile for all team and department managers and still ensure that everyone only has access to salary data for their own team.
Assign structural profiles to the user
You assign structural profiles to users using transaction OOSB. Enter the profile names here and define the validity period.
You can use the exclusion indicator to reverse the authorization: If it is activated, you use your entries to define which objects (from the profiles) the user is NOT allowed to see.
The assignment of profiles to users is recorded in table T77UA. If no profile is assigned to a user in it, the authorization check is automatically performed on the user SAP*.
By default, user SAP* has the structural profile ALL, i.e. full structural authorization for all object types. Alternatively, you can delete the entry for user SAP* in table T77UA. In this case, users who are not assigned to a structural profile will not receive any structural authorizations. You can achieve the same effect by creating an empty profile – for example, a profile containing only objects that are not used by you – and assigning it to user SAP*.
Structural authorizations in Personnel Administration
If you also want to use structural authorizations in Personnel Administration, i.e. for type P objects, a few prerequisites must be met:
- Organizational Management must be maintained 100% correctly.
- The authorization main switch ORGPD in the group AUTSW (transaction OOAC) must be activated (value between 1 and 4)
- The evaluation path must contain the object type P
- What is to be authorized via the structural profiles must also be allowed via the general authorizations. Only if both checks are successful, the user gets access to the requested data.
If these prerequisites are met, the use of structural authorizations also simplifies work in Personnel Administration. This means, for example, that you can dispense with maintaining the “Organizational key” field in the P_ORGIN object and using the administrator ID in the P_ORGXX object, and thus also need fewer roles.