Access Control Management: Access restrictions explained – Restriction Rules
Welcome to the blog series on access control management in SAP Hybris Cloud for Customer (C4C). The series discusses various access control topics in C4C. The goal of this blog series is to provide a complete overview on the access control concept and capabilities in C4C and to let you know on how it works in detail.
Here are the blogs of that series:
- Basics of access control and business roles
- Access Control Management: Access restrictions explained – Access Context
- Access Control Management: Access restrictions explained – Restriction Rules (this blog)
- Access Control Management Example: Global versus local admin
- Access Control Management Example: Access forwarding
- How to analyze access control issues
- How to analyze access control issues – Check User’s Authorization
- 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
Nils Watt – Territory assignment
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!).
- 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.
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.
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.
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.
please find more details on the restriction rules under the following link:
https://www.sap.com/documents/2018/10/347453e7-217d-0010-87a3-c30de2ffd8ff.html
This is great, Bernd - I'm learning so much - THANK YOU!!
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
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
Thanks, Bernd! Really enjoying this series! Keep blogging 🙂
yes - I am just about to prepare my next blog on global and local admins
YIPPIE!!!
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.
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
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
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
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
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?
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.
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?
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.
Hi Bernd,
Thanks a lot for this great blog !
I am looking to implement the same kind of access restriction capabilities, but on custom object, can you help me with this ? (How to setup access restriction to a custom object by business role ?)
I don't know how to restrict access to some records of a custom object by business role ?
Thanks for your help,
kind regards,
Christophe
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
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
Hi Markus,
Thank you for your answer. Incident is on the way...
Best Regards,
Marija
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
Hi Stefanie,
the read access behavior is derived from the join of both roles! Thus the territories are included as well.
Kind regards
Bernd
Hi Stefanie,
I further discussed that topic internally. Can you please create an incident on this behavior.
thanks
Bernd
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
Hey Bernd,
can you help me, please?!
This is all I get from my incident:
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
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
Hi Bernd,
thank you for supporting me.
I reverted back my incident already.
Please inform me about any updates.
Best regards,
Stefanie
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
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
Hey Bernd,
I received the following answer:
Hi Bernd,
Is different access restriction of read and write works now? I have do a test, however can't get the expected result--can read all opportunities, but can edit only some of them.
Hi Bernd,
Sorry for my misunderstanding. I did test again today, and found that the restriction works.
However, the error message 'You are not authorized to change this opportunity' only shows after clicking 'Save' button. Is it possible to show this error message when user click 'Edit' button? I think that would be better.
Hi Lisa,
unfortunately that is not possible.
Kind regards
Bernd
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
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
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
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
May I suggust that you configure a proper partner determination by maintaining relationship? The team member then will be added to the sales documents automatically. I hope this works to you though it may be too late.
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????
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
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
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
Hello Bernd
In your print screens, there are instances of the field highlighted called "proposed". What does this mean and likewise how is it possible to accept/approve it.?
thanks
Andrew
Hi Andrew,
good question. The Indicator shows up in access restriction tab of a business user. Selecting there a work center view you can see the actual access restrictions flagged for that particular user.
The proposed flag indicates the organizational units, the employees and/or the territories the user is assigned to. This flag was mainly relevant in the early times when roles were not yet introduced. It was an indicator to help to maintain individual access rights for a particular business user.
Today the restriction rule in the business role automatically generates the actual access rights of an individual user for example based on its organizational or territoriy assignemnt. The access right results of the restriction rules for individual the user can be checked in this view. It is display only as it comes from the business role assignemnt and its restriction rules.
Kind regards
Bernd
HI, it is possible to restrict the accounts by account hierarchy?, I have just replicate the account hierarchy form ECC to C4C, and I have a problem about restrictions, so,
There is an employee who is assigned as employee responsible for a parent account, but not as employee responsible for child accounts or heararchy. And the responsible of the parent account cannot have access to the child accounts.
Could you help me withs this challenge?
Thanks!!!!!
Hi Francisco,
the standard access control does not consider the account hierarchy. You might be able to approach that by using recently introduced BADI which can be used to manipulate the Account Access Control list with customer specific logic (BAdI CustomAccessControlListWrite --> SAP Cloud Studio)
kind regards
Bernd
Hello,
I am new to the restriction rules. I would like an employee to see people assigned to his service and to his sales organization only. What restriction rule shall I apply?
Thanks in advance
Pankaj
Hi Pankaj,
actually you need to be a bit more specific by naming the work center view you want to set up the access restriction. In case you want to restrict access for the employees (in the people work center) the access context is 2008 - Org Unit, which provides several restriction rules based on organizational assignments. In your case you might want to choose the restriction rule 1 - Sales Organization of Employee. I have not tested it for service organization but my current assumption is that as provided in the documentation it will only consider sales organizations.
Kind regards
Bernd
Hello Bernd,
Thanks for your reply. Yes, it was the restriction rule 1 and it worked like a charm.
Best regards,
Pankaj
Hello Bernd,
My question is regarding the access context - "5 - Service Unit". Currently we have restricted the tickets based on the restriction rule - "01 - Service Units of Employee" and it is working as expected.
Now we are in process of restricting "Unassociated Emails" and i could see the same restriction rule - "01 - Service Units of Employee" for the work center. I tried applying the same but i could not see any difference.
I understand that for "Ticket" WoC, this rule works when the logged in employees service unit matches the ticket's service unit (or) team.
But for "Unassociated Emails", I could not see any service unit data or any other relation to Service Units.
Please explain this access restriction on Unassociated Emails.
Thanks,
Manson J
Hi Manson,
I think there is a high probability that you are right with your assumption that the associated email instance does not have any access relevant data in it by which the access context 5 can determine an access restriction (for example a service unit or an employee).
kind regards
Bernd
Hi Bernd,
Is it possible to set access restrictions based on Sales Organization or Sales Territory for the Export functionality of Data Workbench in C4C.
There is no options available in Access Restrictions for Data Workbench.
Thanks and Regards
Praneesh OB
Hi Praneesh,
the data workbench work center and the export work center view are administrative functions and hence do not have access control capabilities enabled. In the access restriction maintenance screen of the business role you do not find an access context assigned. This indicates, that the underlying work center view is designed without access control capabilities:
Again, the function is meant to be used by the central administrator to manage the data migration activities. Hence access restriction is not relevant here.
Kind regards
Bernd
Hi Bernd,
We are facing the current case :
TOM is member of Sales Unit A
JIM is member of Sales Unit B
JACK is member of Sales Unit B
We are trying to have the following behaviour :
Issues :
Is there a way to deal with that case without going through utterly annoying SDK developments ?
Best regards,
Mathieu
Hello Matthieu,
One easiest way is to create Filter query (one time activity) on Leads by applying the relevant Sales Unit Value in the relevant Sales Org. related field on Leads Advanced Filter screen and save this query and call it for ex: 'Sales Unit B Leads' or anything that is meaningful to you.
BR