Structural authorizations perform exactly the same function, from a business point of view, as general authorizations in mySAP HR and in other SAP components. They control access specifically to data that is stored in time-dependent structures (organizational structures, business event hierarchies, qualifications catalog, etc.).

The data that you want to protect must be stored in a hierarchical structure of one of the Human Resources components (Organizational Management, Personnel Development, Training and Event Management, etc.)

You can grant authorizations for objects that are stored in a hierarchical structure using the structural authorization check. If you specify a root object, you can determine that all objects in the hierarchy under this specified object may also be changed, for example.

This concept guarantees that the maintenance of structural authorizations is kept to a minimum, even if a change is made within the structure, and at the same time that users still only have access to objects that they are responsible for.

This flexibility is achieved in two steps. First by using the (initial) structure built in Organizational Management to define the authorization profiles. And second by using a concept to store authorization profiles that reacts automatically/dynamically to changes in the organizational structure, or in other words a concept that automatically adjusts to the different profiles.

The following example illustrates the advantages of structural authorizations for access to data in time-dependent structures:

An organizational structure divides into three subtrees (organizational units O2, O3, and O4) on the second level, for example. The authorizations of the persons responsible for each organizational unit are also divided up accordingly for each subtree. A user needs three profiles for this organizational structure that allow him or her to read/change data in O1, O2 or O3 AND in all lower level organizational units.

If you were to use the general authorization concept (values in fields) here, you would have to enter all objects under the initial object in every authorization profile.

For the O2 profile and lower level objects, for example, you would have to enter the following objects in the profile:

• O2
• O5
• O6

In other words, you would have to enter ALL objects under O2 in the profile.

You would have to follow the same procedure for all other profiles, which would involve considerable maintenance work to the initial profile and to the organizational structure if changes were made to it.

If the organizational structure was expanded to include the organizational units O11 and O12, for example, you would have to add the O2 and lower level objects profile to include 011 and 012 manually.