Welcome to the blog series on access control management.  The series discusses access control and business roles.  It provides typical examples of roles and access management.  The following are the blogs in this series:

 

  1. Basics of access control and business roles
  2. Access Control Management: Access restrictions explained  – Access Context
  3. Access Control Management: Access restrictions explained  – Restriction Rules (this blog)
  4. Access Control Management Example: Global versus local admin
  5. Access Control Management Example: Access forwarding
  6. How to analyze access control issues
  7. Special Access Control Topics

 

 

The translation of the setup of the access restrictions defined in an unspecific role to the access restrictions of a specific user is handled through the restriction rules.

 

Example:

You have created a role for sales representatives. This role provides access to the work center views Account, Contacts, Opportunity and Sales Quote.  You want to assign this role to all of your global sales representatives in the different organizations. By choosing the restriction rule “Assigned Territories and Employees (for Managers)”. The system will automatically provide access restriction set up to the accounts where a user is assigned in the account team or in the territory team”. As the system generates the access restriction for the user automatically it is not necessary to create a role for each individual territory.

 

 

How does the system actually translate the access restrictions for the individual business users?

 

Sales Representative Nils Watt

Nils is a sales representative of the BFT Company Inc. Organizationally he is assigned to the corporate org unit of the company. He also is a member of the territory “Germany” which has further sub territories assigned. Nils user has the role “BFT DE SALES ASSISTANT” assigned. For the Accounts work center view the access restriction rule “Assigned Territories and Employees (for Managers)” is selected.

Nils Watt  – Organizational assignment

0301_NilsWattOrg.png

 

Nils Watt – Territory assignment

0302_NilsWattTerr.png
Nils Watt User Role

0303_BFTSalesAssistantRole.png
The following screen shots shows access rights for the account work center view of the user of Nils Watt. These access rights were automatically generated:

  • As Nils is assigned as an employee (and not as a Manager) to his organizational unit. He has access granted only for those accounts (and contacts) where he is assigned as a member of the account team (no access to accounts of other account team members!).

0304_NilsWattAccessRestriction.png

 

  • As Nils is assigned to the territory Germany he has access to all accounts which are assigned to this territory but in addition also to all the accounts assigned to its sub territories.

0305_NilsWattAccessRestriction_Terr.png

 

 

Nils’ access is a combination of the employee part of his access context (–> Accounts where he is directly assigned as an account team member) and the territory part of his access context (-> Accounts which are assigned to a territory (and sub territory) he is a member of.

 

The restriction rule of the role which is assigned to Nils’ user has dynamically generated access rights. Dynamically means that a change of his territory assignment will lead to a change of his territory related access rights.

 

Please note that there are some situation where the access for the users of a role must explicitly be update (e.g. the sales area in the employee is changed). In those cases enter the relevant role –> assigned Users –> Update Users. This action will trigger a background job which set the access rights of the assigned users according to their current territory or sales area assignment. The user  update of a role is also an action you can do in case the access control does not provide expected access results (in my blog How to analyze access control issues I will provide some more details on how to proceed in case of issues)

 

Sales Manager Bodo Mann

Bodo is the manager of the BFT Company Inc. Organization. Bodo’s user has the same role “BFT DE SALES ASSISTANT” assigned as for his employee Nils. Bodo is not assigned to any territory:

 

  • As a manager Bodo has access to all accounts where employees of his own organizational unit and sub units are assigned in the account team. Please note that the organizational unit must be flagged as a sales unit (functional unit sales) to be effective in the access restrictions.

0305_BodoMannAccessRestriction_Terr.png

 

Does Bodo also has access to an account where his employee Nils Watt can access because he is member of the territory team of the account but not member of the account team?
The answer is no! The employee part of the access context only considers the organizational assignment of the employees of the manager.
When setting up a role I recommended to use access restriction rules rather than defining specific rules. This might not always be possible for all customer use cases but using restriction rules can reduce the  number of different business roles as the same role can be used for users of different organizations, territories etc. By this maintenance and administration effort on handling the roles can be reduced.

 

0306_RestrictionRule.png

 

The restriction rule can be maintained in the “Access Restriction” by individual work center view. It is depending on the access context of the work center view/business object. In the screen shot above you see the available restriction rules for the access context 1015 – Employee or Territory or Sales Data. Other work center views/business objects which are assigned to different access contexts will provide a different set of restriction rules.

The restriction rules are defined by the standard and cannot be changed or extended customer specifically.

 

 

I have attached an XLS with a  table is intended to provide an overview on our current restriction rule setup

Legend

  • Empl.: The difference between Employee and User is that if the employee is a manger, then for employees also the OrgUnits of the manager are considered (the manager gets access for all employees in his/her OrgUnits). For both managers and employees the own user is added.
  • Workforce: Access based on the employees supervised by the user in the relationship hierarchy
  • User: user only is added, even for managers
  • Org: OrgUnits of the user are added. The function of them is derived from the access context
  • Territory: Territories of the user
  • Partner: only meaningful for users that are partner contacts. The partner of the partner contact
  • SalesArea: the sales areas maintained in the employee’s master data
  • Sorg+Dist: sales organization combined with all distribution channels in the system.

 

0307_RestrictionRuleOverview12.png

0308_RestrictionRuleOverview22.png

0309_RestrictionRuleOverview32.png

To report this post you need to login first.

37 Comments

You must be Logged on to comment or reply to a post.

  1. Ginger Gatling

    Hi Bernd

    I have a question.  I’m on a tenant where my SALESREP user has the restriction: Assigned Territories and Employees (for Managers).

    On this test tenant I have an org structure but territory management is not setup yet.  I’ve noticed that the SALESREP user can see the accounts where they are part of the account team or the owner – so that’s good.  I have two accounts with no owner assigned and no account team.   My questions is – assuming no territories setup, does it make sense that SALEREP01 can see accounts with no owner and no account team assigned?

    Thanks!

    -ginger

    (0) 
    1. Bernd Fleddermann Post author

      Hi Ginger,

      a basic concept in the access control is to show the data when there is no account team member and territory maintained. In this case the system has no handle to determine the access restriction and our architects decided to allow access to these kind of customers.

      In your example exactly this situation is relevat. There are no account team members nor any territories maintained in that account. Hence the system follows the general rule to then open up access to this account until either one of the information is added.

      That is an aspect which need to be considered espectially when accounts are created. Hence it is usefull to have at least a territory derived (this can be triggered through a workflow rule) or at least one account team member is identified.

      kind regards

      Bernd

      (0) 
  2. Prajith Nair

    Hi Bernd,

    Quick question : If I were to look for an option to restrict opportunity transaction types by  business role – can this be achieved?

    Access restrictions control my create / read access.

    Code list restrictions seem to restrict the capability to create specific Opp transaction types; but I seem to be able to view all opp transaction types (regardless of role) when I perform a search.

    Is there a way around this via configuration or am I missing something fundamental?

    Thanks for any guidance on this.

    (0) 
    1. Bernd Fleddermann Post author

      Hi Nair,

      the elements by which you can restrict the access to an opportunity is given by the access context. For the opportunity it is 1015 – Employees or Territory or Sales Data.
      Hence the opportunity type can not be used to set up instance access control for the opportunity.

      Kind regards

      Bernd

      (0) 
  3. Wei Ling Wong

    Hi Bernd,

    We have this scenario. User A is the Account Owner. User B creates an Opportunity for the same Account and is the Owner of the Opportunity. However, User A is not able to view the Opportunity unless User A is added to the Sales Team or Involved Parties of the Opportunity. Is there a solution to allow the Account Owner (in this example, User A) to view all opportunities, activities, etc. of the Account?

    Thank you.

    Regards,

    Wei Ling

    (0) 
    1. Ankur Godre

      Wei,

      Couple of options:

      1. Provide access to A to view Opportunities of B.

      2. If A if the Org unit Manager & B is one of the team members of the Org., A should by default get visibility into B’s Opportunities.

      3. Use Territory Management – This would allow you to provide the access the way you mentioned.

      BR

      Ankur

      (0) 
      1. Bernd Fleddermann Post author

        In addition the opportunity also allows access by the sales data. e.g. the sales are data of the opportunity matches with the sales area data maintained in the employee master of A

        Kind regards

        Bernd

        (0) 
  4. aleksandra gerasko

    Dear Bernd! Thank you for this blog, it is really nicely described 🙂 I have one question for the territory restriction: my user is assigned and restrictedby territory, so I can see in My accounts only those from the specific territory. But when I click “All” I can se others as well. How can I restrict it to the territory ones and only?

    (0) 
    1. Mark D. Huelsman

      In the admin tab you can use the business roles to limit what they see.  When in the maintain business roles on the Access Restriction you can set the accounts for example to Restricted Read access.  There are 8 or so selections there to limit what they can Read. These also work for what they have Write access to.  If one of these does not meet your need you can use the 99 option and define your own. I would not recommend that, that could become a maintenance problem.

      We have our set up with overlapping territories for different product groups. They all can see each others, but not change them. Seems to be working well.

      (0) 
      1. aleksandra gerasko

        Hi Mark, thanks for such a quick reply. We did it like that, but still the user can see in “My accounts” all account assigned to the territory and in “All” accounts – all others, that are not assigned to any territory. My question is: is it possible to restrict the view to only territory assigned ones?

        (0) 
        1. Bernd Fleddermann Post author

          Hi Aleksandro,

          please check for the additional accounts you see listd in the account OWL for your user if they have any restriction relevant information (e.g. territory) maintained. In case the account has no information the system can use to restrict access, the system does not restrict at all.

          (0) 
  5. Marija Fehn

    Hi Bernd,

    I have a question regarding the employee workcenter view.

    Our keyuser who is assigned to a sales organization X is supposed to support also our users that are working within sales organization Y.

    we have two business roles, one for keyusers in sales org X and one for keyusers in sales org Y. now we assigned these two business roles to our keyuser that is working with both sales orgs.

    within the restrictions in the employee data we have defined specific rules which allows our keyuser to see all employess that are assigned to sales org X in one business role and in the other business role the restrictions are made for the other sales org Y.

    now our keyuser is just able to see employess (in WC Employee) from sales organization X, but there is no employee listed from sales org Y.

    Can you figure out why our keyuser only sees employees from sales org X?

    Thank you for your help,

    Best Regards,

    Marija

    (0) 
    1. Markus Penn

      Hi Marija,

      please create an incident describing this issue in detail (user, business role, …) that we can further investigate …

      In general the restrictions in the employee workcenter view should work as expected by you.

      Regards,

      Markus

      (0) 
  6. Stefanie Ehlert

    Hi Bernd,

    Thank you for the great blog post!

    I have a specific question.

    I am working in a project, where we have the following requirement:

    That means one business user should have read access of phone calls restricted by his territories and employee data. But his write access for the some work center view should be restricted only by his employee data. So he will be able to read more phone calls than he can write.

    Do you have experiences, how we can handle that?

    I thought about using multiple business roles and assigning those to one business user.

    This is the combination I tried:

    But in this case the read access is restricted by “territories, Employee (for managers)” and the write access as well 🙁

    Can you help me?

    Thank you in advance,

    Best regards,

    Stefanie

    (0) 
    1. Bernd Fleddermann Post author

      Hi Stefanie,

      the read access behavior is derived from the join of both roles! Thus the territories are included as well.

      Kind regards

      Bernd

      (0) 
      1. Stefanie Ehlert

        Hi Bernd,

        my issue isnt the read access, it is all about the write access. The business user has the write access “territories, employee”, even though this is not defined in any business role.

        I already opened an incident on this behavior, but the responsible agent is missunderstanding my issue and telling me, I have to go to this (your) blog post to find the explanation…

        Thanks,

        Stefanie

        (0) 
      2. Stefanie Ehlert

        Hey Bernd,

        can you help me, please?!

        This is all I get from my incident:

        Incident_Answer.png

        I’ve tried to explain him the issue a few times. I think I do understand him, but I still don’t know, where the write Access “territories, Employee” is coming from. His answer is not answering my question.

        Thank you and best regards,

        Stefanie

        (0) 
        1. Bernd Fleddermann Post author

          Hi Stefanie,

          I have set up a similar use case on a different Business Object in a sandbox tenant I am using on my side and discussed it directly with development. As I was able to reproduce that issue, I have created an incident. I will keep you posted on any updates I get from that process.

          With regads to the reply you have posted out of your incident, I have to admit that the answer from support is not sufficient. Please revert it back to support.

          Bernd

          (0) 
            1. Bernd Fleddermann Post author

              Hi Stefanie,

              my ticket is currently in process by development the are is a critical area hence requires appropriate alignment and clarification.

              I let you know on any updates.

              Kind regards

              Bernd

              (0) 
              1. Stefanie Ehlert

                Hi Bernd,

                thank you very much for your effort, I highly appreciate that!

                I had to reopen the incident on a new tenant hence I didnt get an answer yet.

                Kind regards,

                Stefanie

                (0) 
  7. Saurabh Shrivastava

    Hi Bernd,

    We have 3 service ticket type(Let say T1, T2, T3) out of which we want end user employee can search only 2 ticket type(T2 , T3) under “Employee support” work center view,right now when user go and search then he is able to search all 3 ticket types in “Employee support” work center view.

    Can you please let us know how can I restrict the certain ticket type should not be displayed to employee?

    I created the business role and I tried using access restriction tab and “field and action” tab but don’t know exactly which condition will work. Kindly help.

    Regards

    Saurabh

    (0) 
    1. Bernd Fleddermann Post author

      Hi Saurabh,

      the employee support work center view (ticket) comes with the access context “5 – Service Unit”. This access context comes with the following restriction rules:

      01 Service Units of Employees
        2 Employee

        3 Territories

        4 Managed Service Units

      99 Specific Restrictions

      by these restriction rules you can clarify on how you are able to restrict access to that business object. Here is an Example:
      Service Unit of the Employee –> The Service Unit assigned in the ticket needs to be a service unit the employee is assigned to. The employee has access to all tickets which are related to his service unit

      In the XLS extracts I have provided in this blog you find the further explanation of the other restriction rules of access context 5 – Service Unit.

      The specific restriction rules allows you to define individual access rights within the structure of the access context. Here you are able to assign access to specific service units or territories.

      Coming back to your use case. In order to make an access distinction for the ticket types (T1, T2, T3) you need to specify on whether the ticket type is represented by the assigned employees or the service unit or the territory.

      I hope this clarifies

      Kind regards

      Bernd

      (0) 
  8. Ron Butterman

    Hi Bernd,
    Great blog, but I am still struggling with the following use case:We use territory management to limit the access of data. This works well for reps that manage territories, but we also have (several hundred) specialists that only need access to some specific accounts, which can be in any territory. We can make them an account team member and that provides visibility to the account, but we also need them to see the sales documents (opportunities, sales quotes…) of those accounts. How can that be achieved? Manually adding them to each document is not an option (we are talking 100,000+).
    Regards,
    Ron

    (0) 
    1. Bernd Fleddermann Post author

      Hi Ron,
      The access context 1016 (activities) allows through restriction rule 01 “Obsolete; Territories, Accounts, Employees (for Managers)” to provide access to an activity according to the account team member assignment of an employee. However, this restriction rule only allows a maximum of 500 accounts per employee due to performance limitations hence it is flagged as “obsolete”.

      It is planned for the upcoming releases to provide a similar capability/additional restriction rules also for the access context 1015 (Customers, Opportunities, Sales Quotes, etc). To provide access to a sales document according to the assignment of an employee to the customer. It is planned to check the assignment through the account team and the territory team for both access context 1015 and 1016 with this planned enhancements. Please note that there will still remain a limit on the maximum number of accounts an employee is assigned to.
      Kind regards
      Bernd

      (0) 
  9. Aruna Thakar

    Hello Bernd,

    Great Info..very good blog…I have some doubts on Personnel Admin area….Can we restrict access to employees personnel file by countriwise……..(territory)…Like HR Employee from India can have access to all Employees hired in India only????

    (0) 
    1. Bernd Fleddermann Post author

      Hi Aruna,
      the access context for the employees work center contains the Org Unit. Hence restriction is possible based on organizational assignment but not based on territory assignment.
      Kind regards
      Bernd

      (0) 
  10. Rogier Smit

    Dear Bernd,

    Hopefully you can advice on fulfilling this requirement.

    We have the requirement to restrict account managers in order to grant access ONLY to the opportunities to which the account manager assigned as OWNER. In case the OPPT has been assigned to his colleague (who is in the same sales unit) he/she is not allowed to EDIT the opportunity document. Viewing the document should still be possible in any case.

    So both READ/WRITE access for opportunities that you OWN but only READ access to opportunities you don’t own.

    Please advice on which rule should be selected or how this requirement can be covered.

    Kind regards,
    Rogier

    (0) 
    1. Bernd Fleddermann Post author

      Hi Rogier,
      good question. In order to have a different access behavior for READ and WRITE on the same work center view, please try and test to split the read access and the write access setting in 2 different roles and combine both roles for the particular user. To limit access to the employees assigned in the sales team only. You need to use restriction rules referring to the employee only. The role itself is not being considered as access criteria.
      Please test that through.
      Kind regards
      Bernd

      (0) 

Leave a Reply