Parent & Derived Roles

The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. Its specially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child role derived from a parent role will have all attributes (transactions/ authorization object values) same as it parent except the values of the Organizational Level fields (plant, company code, sales organization). Thus maintenance is simplified as only the org levels need be maintained at the derived role level. This also ensures that there is no opportunity to make mistakes during authorization maintenance for the multitude of derived roles and also reduces testing effort for roles.

Creating the parent role follows the same process as creating any other single role. In the example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company code, sales orgs.

PFCG - Define Parent Roles
PFCG - Define Parent Roles

With the parent already defined we create a child role “Z_CREATE_SO_US” which allows SO creation for the US companies. We maintain the parent role name as shown below.

PFCG - Derived Roles - Definition
PFCG - Derived Roles - Definition

The menu for a derived role can not be individually maintained as all entries are inherited from the parent.

PFCG - Derived Roles - Menu can not be changed
PFCG - Derived Roles - Menu can not be changed

Now we maintain the org levels values relevant for the child role. In the example below, we have used a dummy value of @ but in a production system the correct value for org levels should be used. The other other need not be maintained at this stage. Now we save the authorization entry for the derived role.

PFCG - Derived Roles - Maintain Org Levels
PFCG - Derived Roles - Maintain Org Levels

To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non org level values from the parent to the child role and generates the profiles for both.

The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows different business process in its different subsidiaries.

39 thoughts on “Parent & Derived Roles

  • April 29, 2011 at 8:16 am
    Permalink

    Hi,

    thanks for your articles. What I’m interested in is the value-roles approach. What about your experience with creating different roles for Transaktions (T_CODE), “common objects” and org-levels and assigning a set of these roles to a user knowing that the object will be provided by the additive auth. buffer?

    Maybe you can come up with an article about that concept.

    Thanks,
    Gerhard

    Reply
    • April 29, 2011 at 5:00 pm
      Permalink

      Hi Gerhard,

      Thanks for the idea. I just started on a post about Value Roles. Should be ready in a few days. However, I will confess that I am somewhat skeptical about the efficacy of value role based security design. So you might find the article just a bit biased:-)

      Regards,
      Aninda

      Reply
  • August 4, 2011 at 3:33 pm
    Permalink

    topics & desp are good

    Reply
  • September 18, 2011 at 6:07 pm
    Permalink

    hello aninda

    How you doing. will you please answer one of my questions
    if u assign a role to user. He is executing the role with out problem but my question is user is executing tcode but he got perticular screen with missing tabs , how could we solve this problem

    awating for your answer

    Regards
    krish
    thisiskrish@hotmail.com

    Reply
    • September 19, 2011 at 5:35 am
      Permalink

      Hi Krish,

      If you are getting access to the tcode but some options are missing, there might be subsequent security checks which are failing for the user. Use the security trace (transaction ST01) to investigate the missing access. There is a post on this site which mentions the details of how to use the security trace.

      Regards,
      Aninda

      Reply
  • October 14, 2011 at 2:14 pm
    Permalink

    Hi Aninda,

    I need information/step by step procedure about CUA set up..

    Kindly post me

    Reply
  • October 25, 2011 at 9:53 am
    Permalink

    hi Aninda,

    thanks for the information..it is v productive.

    Regards,
    Rakshith

    Reply
    • March 1, 2012 at 9:58 am
      Permalink

      1.client should be created by using scc4(tode).
      2.logical systems should be defined by using sale/bd54.
      sid.
      3.Rfc connections should be defined by using sm59(tcode).
      two users are created parent&child systems.
      user type is (communication user)
      also roles should be assigned to users.
      sap_bc_usr_cua_client.
      sap_bc_usr_cua_rfc
      sap_bc_usr_cua_central_setup.
      sap_bc_usr_cua_central_client.

      Reply
  • October 29, 2011 at 8:18 pm
    Permalink

    Hi Aninda,

    thanks for your first class explanation of authorization issues. Just want to know the following topic:

    I want to add a new auth. object to a parent role which has about 20 child roles due to company codes and sales orgs.

    I have changed the parent role with the new object and generated properly with the red-white beach ball and then transported to QA. But the in the target(QA) system, all the child roles had red lamps in auth. flap which were previously green ! What happened ? Will bepleased for your advice.

    Thanks in adv.

    Kumar from Germany.

    Reply
    • October 31, 2011 at 5:45 am
      Permalink

      Hi Kumar,

      The entire concept of the lights in the authorization tab turning green/yellow/red is controlled by the timestamp of the role and profile. Did you generate the child roles (push authorization values) after inserting the object to the parent? Ideally both parents and child roles should have been generated and roles and profiles of all should have been transported to QA.

      Regards,
      Aninda

      Reply
  • April 20, 2012 at 8:26 am
    Permalink

    Hi Aninda,

    its aweasme site. i am fresher and working in MNC in SAP Security. i am struggling in. can you guide me how i should go and learn ?

    Reply
    • April 22, 2012 at 5:19 am
      Permalink

      The site is expressly for freshers like you. Go through the articles in the order they appear in the drop down menu or the left hand side menus. The articles under “Getting started with Security” is a good place to start.

      Reply
  • May 4, 2012 at 6:04 am
    Permalink

    wen wil go for excute and simulate in grc rar

    Reply
  • April 26, 2013 at 10:03 am
    Permalink

    Hi Aninda,

    the back ground job “PFCG..TIME_DEPENDENCY” is turning the green-buttoned authorizations into “Yellow”, how to stop it !
    I have changed the variant “Without clean-up”, but still it’s done that non-sense !

    ‘will be pleased for your advice.

    Thanks

    Kumar Mitra
    Germany
    ===========

    Reply
  • May 29, 2013 at 3:34 am
    Permalink

    Hi

    I want to know the concept of single ,composite and derived roles.what is the purpose of using this

    Reply
  • June 5, 2013 at 10:42 am
    Permalink

    Thanks…….. ANINDA……good article…..

    Reply
  • June 20, 2013 at 1:41 pm
    Permalink

    Thanks….
    Good article for all who are working on sap security.

    Reply
  • September 1, 2013 at 12:24 pm
    Permalink

    Hi ,
    I would like to know if there is a way to maintain different org levels in a derived roll with different activity? for example
    1. activity = 03 , company code = 1000
    2. activity = 02 . company code = 2000

    thanks

    Itai

    Reply
    • September 3, 2013 at 10:34 pm
      Permalink

      You are out of luck. I would suggest that you re-think your design!

      Reply
  • October 10, 2013 at 4:05 am
    Permalink

    Hello,

    Can you tell me the correct way after we have made the change
    to the Org Level Values of any existing derived role.

    1) After making Org Level Changes, we GENERATE Profile for that derive role there. Again go to master and click on Generate Derived roles and then move them both in a TR?
    2) After Org Level Change, we only SAVE the Derived role and not Generate the profile.Go to Master Role and click Generate Derive roles and transport both in a TR?

    Reply
    • October 28, 2013 at 10:25 am
      Permalink

      Both of the two processes will work. The important thing to remember is to ensure that you click the generate derived roles button from the master. Also if you create a transport for a derived, SAP automatically includes the master in your transport.

      Reply
      • November 27, 2013 at 4:09 am
        Permalink

        Hi Aninda. Thanks a lot. I have 1 related question for which I need little help. It is urgent.

        I am making changes to the Org Level (adding/removing Plant codes)….So…this is what I do … (Please correct me)

        1) Go to the Derived Role,
        2) Auth Tab Option – CHANGE AUTH or EXPERT MODE (Read and merge with new) …
        Here i selected ‘Expert Mode’ (Read old data and merge with new) …
        In Auth screen, I saw 1 YELLOW Button in S_TABU_DIS for a table. So, I made this as INACTIVE (as it was inactive in MASTER ROLE). This made the lights go Green.
        3) Then I made the Org level changes by adding/removing Plant codes as required.
        4) Click on ‘Generate’ for generating profile of this Derived Role.
        5) Go to Master Role, go to CHANGE mode
        (Que-DO I need to keep only DISPLAY MODE & click on ‘Generate’ profile in auth screen).

        In Auth Tab, Do I need to Select CHANGE AUTH or EXPERT MODE ?
        ONce I go to the Auth Screen, I will Click GENERATE PROFILE.

        (Que- Do I need to click on GENERATE DERIVED ROLES Roles.)
        6) Come out of Maste Role.
        7) Create a TR with Derived and Master both.

        Reply
  • October 10, 2013 at 10:23 am
    Permalink

    Hello,
    i see that the changes once made in child roles, eg: cost center are lost once i update some information in Master role and generate it, is there a way in which i can handle such situation.

    Reply
    • October 28, 2013 at 10:26 am
      Permalink

      You are not suppossed to update anything other than org level values in child roles.

      Reply
  • October 16, 2013 at 8:01 am
    Permalink

    Hi,

    I have a query related to organisational levels.
    if we change the value of organisational levels in derived roles will it effect the parent role or there will be some error?

    Thanks
    Abhishek

    Reply
    • October 28, 2013 at 10:27 am
      Permalink

      Nope. Org Level values are suppossed to be updated in the child roles.

      Reply
  • October 17, 2013 at 9:12 am
    Permalink

    Hi Aninda,

    I am working on master and derived role, I have updated the activities in Master role and pushed the changes to derived roles. now I need to carry the changes to Production system. DO I need to transport all derived roles or Just master roles to Production.

    Reply
    • October 28, 2013 at 10:23 am
      Permalink

      You would need to transport both the master and derived roles.

      Reply
  • March 25, 2014 at 3:11 pm
    Permalink

    Hello Aninda,

    Thanks a lot for this wonderful site.I nned your help on one issue.

    There is a requirment from business to add and remove a tcode only from 1 derived role out of 5 derived roles present for a parent role.
    Is it possible somehow to achieve this.

    Reply
    • April 10, 2014 at 12:09 pm
      Permalink

      This cannot be done. All derived roles will have the same tcodes.

      Reply
      • June 25, 2015 at 7:04 am
        Permalink

        Hello Mayank,

        It is possible to add a tcode in derived role separately.

        Process:

        –> add S_TCODE auth. object in dervided role
        –> Under this object add the tcodes which you want to add (in TCD field)
        –> after that add all associated authorization objects manually
        –> maintain the field values as per your requirement
        –> Save the role and generate the profile

        Regards
        GS

        Reply
        • July 27, 2015 at 1:48 pm
          Permalink

          This is not a feasible solution. The newly added S_TCODE values will be wiped out once the values are pushed from the master role. Also it defects the function of derived roles where the derived roles and master roles only differ in the org level values maintained in them. Thanks

          Reply
  • April 4, 2014 at 1:33 am
    Permalink

    Hi,
    Good day..I have a query regarding role transports involving Parent and derived roles.

    1. I know that when we transport Derived (Child) roles, the Parent role gets included in the Transport. This I understand is the SAP standard process.
    Would it be possible to provide more information related to the SAP standard process regarding this.. A link to refer would definitely help..

    2. Due to the inclusion of the master(parent roles) we end up getting a lot of Transport collisions. We have approximately 100-150 Child roles per master role. As a result, though, while there might be no actual changes on the Master role, and maybe only an Org level update on the child roles for different locations, we still have to look at a lot of transport collisions, due to changes for different locations.

    My questions are :
    1. If we remove the Parent/Master role from the transport, would it cause any issues. Would it also affect the Inheritance in any way or cause any authorization issues later on..
    2. Also, Will transporting only the Master role and then deriving the child roles work in the above scenario..

    Please advise..

    Regards,

    Prakash

    Reply
    • April 10, 2014 at 11:51 am
      Permalink

      Hi Prakash,

      Unfortunately I don’t have a link to “official” documentation talking about the transport process.

      If you are updating org levels, you shouldn’t be have to touch the master roles at all. Just update the affected child roles with new values and generate these roles individually. Even if the masters are automatically included in the transports, there won’t be collisions as the same master roles with the same time stamps would be included in all the transports containing the master. I don’t believe its a good idea to remove the masters manually from the transports.

      Thanks,
      Aninda

      Reply
  • September 30, 2014 at 11:18 am
    Permalink

    Hi Aninda
    please provide all authorization objects for org level fields

    Reply
  • October 27, 2014 at 12:40 pm
    Permalink

    Hi Aninda,
    I am impressed with your website and the intelligent articles you post, and I wondered if you could help me.

    I am implementing the master \ derived concept for HCM at present and I have an issue with P_ORGINCON authorisation object. It would be very useful to create one master role and then control child roles by PERSA and PROFL so that different structural auths can be assigned for certain ‘areas’ of the organisational structure.
    eg. with PERSA restricting by location and then PROFL by business stream (cut across org structure).

    At present I have the option of:
    a) entering all values in PROFL in master role and relying on table T77UA being well maintained to only allow a single, appropriate profile to be brought through for each user.
    b) leaving PROFL blank in the master and maintaining the values individually in each child role after every update of the master role.

    Can you advise if it is possible or advisable to set up PROFL as an organisational level data value via PFCG_ORGFIELD_CREATE so that it can be maintained alongside PERSA?
    What issues do you foresee in doing this?

    Many thanks in advance

    Reply
    • October 28, 2014 at 5:59 pm
      Permalink

      Hi Andy,

      It all boils down to your requirements. I have used both PROFL and PERSA as both org levels and normal authorization fields in different systems. The one problem that sometimes comes up with PROFL as an org level is if the same role has different structural restrictions for different infotypes.

      Thanks,
      Aninda

      Reply
  • May 27, 2015 at 10:18 am
    Permalink

    If PROFL is set as organizational value, you state, that you had issues, if more than one structural profile is used in the same role. But is the problem, not only, that you cannot control this from the organizational tab?

    In the question, is it statet, that it would be possible to leave the PROFL with *, and then relate on the entries in T77UA. But is it not so, that the P_ORGINCON is using the profile entered in PROFL and not the profile in T77UA?

    Thx in advance
    Birgitte

    Reply
    • July 27, 2015 at 2:02 pm
      Permalink

      You can certainly have PROFL as * in the role and control the actual assignment via the OOSB entries. Whether to promote it to an Org Level is decision based on your design of the roles. Thanks.

      Reply

Leave a Reply to Niket Cancel reply

Your email address will not be published. Required fields are marked *