With SAP R/3 4.5x, SAP introduced the concept of the derived role. Since then, a common use of a derived role is to segregate sensible organizational levels. For example, if you have a buyer job role (which is a composite role), you can derive all roles by country. You can obtain some version of the buyer job role localized by country (where each country has different sensible organizational levels). Another example is purchasing groups: If you segregate every buyer by purchasing group, you can do it via a derived role.

Using the Enterprise Role Management (ERM) component of SAP BusinessObjects Access Control, you can create and maintain derived roles in an authorization concept that results in improved governance, quicker maintenance, and better performance.

Create a Derived Role

Use transaction PFCG to create a role (e.g., Z_AP_FI_TEMPLATE) (Figure 1). Define a technical name (e.g., Z_AP_FI_TEMPLATE) and enter a short description or a more detailed description in the Description or Long Text fields, respectively. Afterward, you can insert a transaction code in the Menu tab and close all open objects in the Authorizations tab. All authorization objects should be closed with at least one value. Otherwise the Authorizations tab remains incomplete, with the traffic light a different color than green. Open objects are all the objects for which the SAP system has not defined a value by default.

Figure 1

Create a template role

This role contains a menu and all standard authorizations. Figure 2 shows how to create a derived role. In the Description tab, insert the template role to which you want to link (e.g., Z_AP_FI_TEMPLATE). Click the Yes button to confirm in the pop-up screen.

Figure 2

Create a derived role

When you create a role, a record is inserted into table AGR_DEFINE with the role and description. When you create a derived role, field PARENT_AGR is filled with the imparting role. When you edit the Authorizations tab (after inserting at least a transaction code into the tab menu) records are created into AGR_1251 with all authorization objects and values in this authorization role. The following tables are the main ones involved in transaction PFCG for documentation and monitoring of derived roles:

• AGR_DEFINE: Role definition (Figure 3). This table contains master data of all types of roles (i.e., simple, derived, and composite).
  • AGR_NAME: Role name
  • PARENT_AGR: Name of imparting role (i.e., template role)
• AGR_1251: Authorization data for the activity group. In this table, you can find all authorization objects and values in a role.
  • AGR_NAME: Role name
  • OBJECT, AUTH, FIELD, LOW, and HIGH
• AGR_1252: Organizational elements for authorizations. In this table, you can find all organizational levels intercepted (by the authorization object) and values in a role.
  • AGR_NAME
  • VARBL, LOW, HIGH

Figure 3

AGR_DEFINE – role template and derived role

The organizational-level master data is stored in tables USORG and USVAR with organizational levels, variables, and texts. (For more about this, see SAP Note 323817.) After connecting the role template with the derived role, the derive role icon (circled in Figure 4) appears in the Authorizations tab in the template role. You use this to transfer authorization data from the template to the derived role. The maintenance is now only at the template role and all derived roles are aligned and updated automatically. The standard program to adjust derived roles is SUPRN_REGENERATE_DEPENDENT. For more information, see SAP Note 560074.

Figure 4

Adjust the derived role

Figure 5 shows the Authorizations tab and the Organizational levels panel of the template role. All organizational levels have a * value. You can also see that there is an authorization object that is inactive: S_ALV_LAYO.

All authorization object fields of organizational levels assume, in this case, the * value based on input into the organizational level panel. After adjusting the role, the Authorizations tab now shows the organizational levels in the organizational level panel. All authorization object fields at the organizational level take those values (e.g., company code with value 1000, business area with value 50) (Figure 6).

Figure 5

Authorizations tab for the template role

Figure 7 shows the same authorization object (F_KNA1_BUK) in the Authorizations tab of the role template (Z_AP_FI_TEMPLATE) and in the Authorizations tab of the derived role (Z_AP_FI_DERIVED). BUKRS is filled in as the company code for the authorization object F_KNA1_BUK; this is an organizational level field. This field assumes the organizational value inherited from the organizational panel. The role template assumes the value * and the derived role assumes the value 1000.

Figure 7

Comparison between an authorization object with an organizational field into template and derived role

An authorization concept based on the use of composite roles and derived roles has some advantages. There’s a role template in which the tab menu, and consequently the Authorizations tab, are updated and several roles are derived. When a change in the menu (e.g., adding a transaction code) or in the Authorizations tab (e.g., new authorization object) is made, all derived roles are aligned. The daily management and the upgrade phase are improved with this architecture.

Governance

You should avoid some errors to ensure good governance in the authorization concept I’ve explained.

For example, the maintenance of organizational levels is not advised at the field level but only in the organizational level panel, as shown in the Define Organizational Levels pop-up screen (Figure 8). If you try to edit directly at the field level, a panel appears (Figure 9). See SAP Note 314513 for more detail.

Figure 8

Maintain organizational levels by panel

Figure 9

Individual maintenance at the organizational level

To find all roles that are not aligned, you can do a query in table AGR_1251. The query can search all organizational level fields (tables that contain organizational level USORG_DB) and catch all the fields not inserted through pop-up organizational levels. Figure 10 shows a query for searching all organizational levels in a role. Figure 11 shows the result of the query when the value in the organizational level field differs from $BUKRS.

Figure 10

Query on AGR_1251 for finding organizational values not aligned by panel

Figure 11

Organizational value maintained by field editing

The report AGR_RESET_ORG_LEVELS is standard and allows you to replace field-level editing. See SAP Note 804371 for more information. The other way is to find all errors and correct them by entering the authorization role (expert mode > Edit old status) and deleting the field maintained manually. Figure 12 shows the value 4000 in the BUKRS organizational field. You can manually delete the field not aligned at the pop-up organizational levels by clicking the garbage can icon, then the field takes the value inserted in the organizational levels pop-up shown in Figure 8.  

Figure 12

Delete organizational value maintained by field editing

If it’s possible, use a point value instead of a range on the organizational level, because a range allows for a lack of governance. For example, if you have several company codes (e.g., IT10, IT20, and IT30), do not use IT* to authorize all company codes that start with IT code. Instead, enter into authorizations IT10, IT20, IT30, and so on. If you cannot use a point value, read SAP Note 136647. If an authorization value contains other characters after an asterisk, the kernel ignores these characters during the authorization check. For example, the value A*B* is actually interpreted as A*.

Configure ERM to Use a Derived Role

Now I’ll show you how to configure ERM to manage the role derivation process. After post-installation tasks, it’s important to manage the derivation phase and configure these features. If these activities are not carried out, you cannot create roles.

Step 1. Create a methodology with a process, derivation steps, and actions (Figure 13). You reach this screen by going to the Configuration tab and then Methodology > Process.

Figure 13

Create a methodology

Figure 14 shows this methodology (e.g., DERIVED_ROLE in Figure 13) defined. You can see the process ID with the description and the status enabled or disabled based on whether the light bulb is on or off in Figure 13. Figure 14 shows all steps in this process. For the purposes of this article, the DERIVATION step is the important one.

Figure 14

Define a methodology with derivation step

Go to the Apply To tab to see where to insert a condition group. A condition group can dynamically activate a methodology based on some attribute during the creation of a role with ERM. For example, you can define that if a new role has the business process Warranty, then the process methodology does not contain the risk analysis step. Before inserting a condition group, you must define it on the ERM Configuration tab under Condition group.

For documentation purposes, you can click the Detailed Description tab and enter the appropriate information, such as “This methodology is used to create derived roles for the rollout of Italy.”

Step 2. Set up a naming convention for a simple role and a derived role (Figure 15). In the Configuration tab of the Naming Convention node, you can define the naming convention. The rules of the naming convention are automatically determined based on your attribute choice (Figure 16).

Figure 15

Define a naming convention

Figure 16

Composing a naming convention for a derived role

Fill in the Name. Select the System Landscape and Role Type (e.g., Derived instead of Simple or Composite) and set Enforced to Enabled so the naming cannot be overridden by the user during role creation. Then select an attribute (e.g., Free Text) for the naming convention. For derived role naming, it’s important to insert the main derived organizational level along with a value and master role. For an example of a naming convention, see Table 1.

Table 1

Example of naming convention for derived roles

A possible naming convention schema for a derived role is shown in Table 1. For example, for WM:D_020_M_BUKRS_7000 the free text is:

• 4-4: Type of role (this case derived = D)
• 6-8: Incremental number for derived role based on master role
• 10-10: Type of activity role (maintain role, edit role, and view role)
• 22-24: Incremental number at derived role level

With this naming convention, you can quickly find the master role (replacing D with T) managing different organizational value mapping with the same primary organizational field with an incremental name (position 23-24 in Table 1).

• WM:D_020_M_BUKRS_7000_01

• WM:D_020_M_BUKRS_7000_02

Organizational Value Mapping and Mass Maintenance Features

ERM also has organizational value mapping features that you can reach from the Org. Value Mapping node in the Configuration tab (Figure 17). This links a primary organizational level with a secondary organizational level. After defining the business structure for every country (e.g., company code or sales area) you can use the structures to automate population of the organizational level. If there’s a company code value 3400, then all other organizational values assume the pre-defined value when you set these features.

Figure 17

Organizational value mapping configuration

To create a new mapping, click the Create button (Figure 17). Then in Figure 18 you can enter a Mapping Name, a primary Derived Org. Level, and the Org. Value From value. In the Mapped Org. Levels section, you can enter the organizational level linked at BUKRS UK 3400 and the From value. Then any secondary organizational values associated with the primary field will be automatically prepopulated with the 3400 value.

Figure 18

Organizational value mapping configuration

Impacted Master Roles and Impacted Derived Roles are two features that allow you to align the roles created (template or derivatives) to the organizational mapping setup. If a role template intercepts the primary field set in the mapping of organizational levels, ERM proposes to generate the derived role with the specification in the mapping (Figure 19). Click the Continue button to generate a new derived role (e.g., AM_BUKRS_3400) based on the mapping.

Figure 19

Impacted master roles

Impacted derived roles are derived roles that contain the primary organizational value level and one secondary value not filled or as *. If only organizational level mapping is used, you can deactivate derived organizational value editing by selecting No from the dropdown next to Allow editing org. level values for derived roles in the Miscellaneous node (Figure 20).

Figure 20

Allow editing organizational level values for derived roles

During the management of roles, the Change button is disabled by default (Figure 21). ERM does not allow users to edit the derived role as standard, which enforces best practices around role creation and maintenance so all master and derived roles stay in synch. For more information, see SAP Note 1243051.

Figure 21

Change button disabled

To adjust derived roles, you can use the Mass Maintenance feature on the Role Management tab (Figure 22). Click the Generate option and check the boxes next to the roles that you want adjust. Click the Mass Generate button to proceed with your request.

Figure 22

Mass-adjust derived role

Role Derivation

This section explains how to use role derivation in ERM to create a single derived role or multiple derived roles at the same time. In the Role Management tab, follow menu path Role > Create to create a role (Figure 23). When the arrow-shaped tab is green (e.g., Definition), the step is completed. When it is yellow (e.g., Define Authorization), it is a work in progress, and if it is blue, it is not yet treated.

Figure 23

Create a derived role

After definition of a role template, you can define derived roles by clicking the Derived Roles button (Figure 24). A derived roles window appears and you can create all derived roles (Figure 25). Click the Create button and a predefined naming for the derived roles appears (Figure 26). If you choose a primary organizational level, all other organizational fields populate as defined into organizational value mapping.

Figure 24

Define a derived role

Figure 25

Derived roles window

Figure 26

Derived role naming

You can choose which primary organizational level you want to use by going to the Role Management tab, following Roles > Create, and checking the boxes next to the appropriate Mapping Name field (Figure 27). Then you can view the other organization levels that are pre-populated (Figure 28).

Figure 27

Multiple organizational value mapping for a primary organizational level

Figure 28

Organizational value mapping results

After creating the derived role via the Create button (Figure 29), the profile name (SYS_GEN_1) is created automatically by the back-end system on the profile. Then after the generation step, the roles are created in the back-end system (Figure 30).

Figure 29

Create derived roles

Figure 30

Roles created in the back-end system

After that, the derived roles are created in the back-end system (Figure 31). Then ERM automatically inserts the correct organizational value mapping on the organizational level panel (Figure 32).

Figure 31

Derived roles created in the back-end system

Figure 32

Organizational level mapping into derived role