Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Derived roles and org levels

10 min

Listen to this lesson

0:00 / 6:55

Contoso posts supplier invoices in company codes 1710 and 1810 today and will add 1910 for Alternadores del Norte in Wave 2. The task is the same everywhere; only the company code differs. Building three independent roles would triple the maintenance and guarantee that they drift apart. Derived roles solve this: maintain the function once in a master role, and vary only the organizational values.

Organizational levels

Some authorization fields are defined as organizational levels: company code, plant, purchasing organization, sales organization and similar. PFCG treats them specially. They are filled through the Organizational Levels dialog for the whole role at once, and they are the fields that derived roles are meant to vary. SAP's course notes that filling them in the dialog keeps authorizations in Standard status; typing them into the tree marks them Changed.

How derivation works

A derived role refers to an existing role, which SAP calls the imparting role; Contoso calls it the master. The reference is entered in the Derive from Role field on the Description tab. SAP's course spells out what is inherited and what is not.

In the role data, a derived role points to its imparting role, holds its own org level values and carries its own users.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-201
ElementInherited from the imparting role?Maintained in the derived role?
MenuYes, immediately; changes in the master apply at onceNo; the derived menu cannot be edited
Authorization values (non-org)Yes, copied when derived roles are generated from the masterNot meaningfully; they are overwritten by the next push
Organizational levelsOnly on first fill; existing values are not overwrittenYes; this is the point of the derived role
User assignmentsNoYes; users are assigned to the derived role
What a derived role inherits, per SAP's authorization course.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-201

Keeping derived roles in step

Two functions move values from master to derived roles. Generate Derived Roles, started from the imparting role, copies the normal authorization fields, but not the organizational levels, to all derived roles and generates their profiles. Transfer Data, started from a derived role, is usually used for the initial fill and copies all general authorization values from the template. SAP's course adds that organizational levels already maintained in a derived role are not overwritten (SAP Note 314513).

Generate Derived Roles pushes from the master and leaves org levels alone; Transfer Data pulls from the template, usually for the first fill.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-201
  1. Build the masterZCMC_AP_INVOICE_POST: menu and all non-org values; org levels left for derivation
  2. Create derived rolesZCMC_AP_INVOICE_POST_1710 and _1810, each with Derive from Role set
  3. Fill org levelsCompany code 1710 or 1810 in each derived role through the dialog
  4. GenerateGenerate Derived Roles from the master pushes non-org values and generates profiles
  5. Change laterChange the master, then push again; org values in each derived role stay
  6. Wave 2Create _1910 from the same master; fill 1910; generate; test
Contoso's master and derived role workflow.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-201

SAP's course points out a difference from composite roles that helps when building: a derived role has its complete menu the moment the reference to the imparting role is saved, because nothing is read or merged. Its authorizations, on the other hand, start empty until data is transferred from the master. Nadia's team therefore always runs the initial transfer before filling org levels, then checks the traffic lights: a red light in a fresh derived role is expected and means the org values are still to be entered.

Design rules

  • Only org levels differ. If two variants need different non-org values, such as document types, they are different master roles, because the next push overwrites non-org values in derived roles.
  • Never maintain menus in derived roles. The menu belongs to the master; that is what keeps the variants identical.
  • Check org values before pushing. SAP's course notes existing org values are kept; a wrong value stays wrong until someone fixes it.
  • Cancel inheritance only deliberately. It turns the derived role into a normal role, and SAP says the cancellation cannot be undone.
  1. Do the variants share the same menu?Yes → next · No → separate master roles
  2. Do they differ only in organizational level values?Yes → derived roles from one master · No → separate masters, or move the difference into an org level
  3. Will new org units be added later, such as 1910?Yes → derived roles make it a small change · No → derived roles still reduce maintenance
When derived roles fit.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-201

What would you do?

A finance analyst asks Nadia to let users in company code 1810 post with document type KR while 1710 users post with KR and RE, using the existing derived roles. What should she do?

Key points
  • Derived roles inherit the imparting role's menu and non-org values; they vary organizational levels.
  • Generate Derived Roles pushes non-org values and generates profiles; existing org values are kept.
  • User assignments are not inherited; menus cannot be edited in derived roles.
  • If variants differ in non-org values, use separate master roles.

Check your understanding · not graded

Lesson check

  1. 1. What is the main benefit of derived roles?

  2. 2. Where is the parent role entered for a derived role?

  3. 3. What does Generate Derived Roles copy from the imparting role?

  4. 4. Which element is NOT inherited by a derived role?