Access Control Management: Access restrictions explained – Access Context
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 (this blog)
- Access Control Management: Access restrictions explained – Restriction Rules
- 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 previous blog mentioned that each object is controlled by the access context. This access context is a characteristic of the work center view/business object. In the following screenshot, you can see that the work center view Account has the access context 1015 – Employee or Territory or Sales Data.
The access context 1015 is also relevant for Opportunities, Sales Quotes and other business objects. Other business objects such as the product may have different access contexts assigned. The access context is a characteristic bound to the work center view/business object. It is defined by the standard set up of the business object and cannot be changed or enhanced. Hence the access control capabilities for a certain business object works in the defined structure of the access context. That also implies – if there is no access context defined for a work center view/business object a distinct instance base access control setup is not possible for that particular entity.
For custom BOs created with the SAP cloud development studio access control can be inherited from a standard business object through association. In addition it is also possible to define a custom BO specific access control context related to employees or territories.
Example for Access Context:
The work center view “Accounts” has the access context 1015 assigned (Employee or Territory or Sales Data). This implies that the access to an account can (only) be controlled based on the following criteria:
EMPLOYEES directly assigned in the account team –> I have access to all accounts where I am member of the account team (independent of the role assigned); or my manager has access to all accounts of EMPLOYEES of the functional unit (organization) for which he is assigned as a manager.
TERRITORY team –> I have access to all accounts which are assigned to a territory I am a member of. Accounts assigned to territories which are sub territories of my territory are also accessible. Please note that the work center territories where the territories can be maintained works with a different access context – 1010 Employee!
SALES DATA – This is a capability introduced with 1508 –> I have access to all accounts which are assigned to a sales area I am eligible for. The assignment of my relevant sales areas can be maintained in the employee master independent of my actual organizational assignment.
For customers who started to use the system prior to the introduction of sales area in the access context. A scoping option was introduced to ensure compatibility with the access behavior before. That compatibility mode is active for those customers by default and ensures that the sales area access restriction is only effective for accounts with either an account team member or a territory assigned. For customers who started to use the system after 1605 the compatibility mode is not active by default – an account w/o territory and account team member is accessible only when the sales area matches.
This scoping option can be reached in the Business configuration (Built-in service and support –> System Management –> User and Access Management –> Compatibility mode for Access Context 1015 – “Do you want the Access Context 1015 – sales area restriction to be effective only for objects with employee or territory assignments”.
In some cases it might happen that an account is initially created and hence has no access restriction relevant data maintained such as a directly assigned employee or a territory (aka homeless object instance or unassigned data records).
In this situation the system is not able to determine on how to restrict access for a certain user on this account. Here the system is designed to react access tolerant and it will provide access to the object instance by default. This behavior is also relevant for other business objects.
If that is not desired it is possible to change the default access behavior of the system in scoping (scoping option available since release 1702). This option allows to not show object instances w/o any restrictive content (unassigned data records)
Business Configuration –> Scoping Element: Built-in Service and Support –> System Management –> User and Access Management: Tick question “Do you want in general restrict access to data records that do not contain any access relevant content”.
If this option is set the “Compatibility mode for access Context” 1015 should not be activated, otherwise the authorization restriction would not be considered for data records which only have sales area data maintained.
Read/Write access can be restricted on Work Center View (Business Object) level.
Question:
Consider the following scenario for account Widgets Inc.:
For Widgets, Inc, Violet is assigned as the owner of the account. She is the designated employee responsible. Violet’s business role provides access context to accounts by employee. Violet’s business role provides her only access to accounts that are owned by Peter.
The question is: Can Violet see the account Widgets, Inc?
The answer is no: Violet cannot see it because access context outweighs the role employee responsible. Even though she is the employee responsible, her access restriction settings in the role assigned to her only provides access to accounts that are owned by Peter.
Awesome 😉
Very good info 🙂
Great stuff! I'm learning a lot from this series!
Thanks, Bernd!!
We create territories based on zip codes. For this question we have two person calling on a couple zip codes. We have created two territories as we have sales and service sales persons calling on a block of zip codes. There is overlap. So a sales person has zip 12345 and 123456 - Territory 1. The service person has zip 123456 and 123457 - Territory 2. So for accounts in zip 12346 we would like both persons to see each others activity. Is that possible?
Hi mark,
yes, the assignment of multiple territories is possible. This needs to be activated in the Business Confuguration (Work Center: Business Confirguration --> Implementation Projects --> Edit Project Scope; Questions --> Sales --> Account and Activity Management Territory Managemnt: "Do you want to assiggn an account to more than one territory")
With the activation of multiple territories the territories are shown in the account in an own facet "Sales Territories".
I hope that helps
Kind regards
Bernd
We have multiple territories configured. That is working fine. The account has two territories. Each rep can see the accounts so that works. The issue is we would want each other to see each others appointments and other activities. Just so they have awareness of the activity at the customer. They sell different things to the customer, one new equipment, the other service and parts. Is there any thing in the roles or other areas that would allow them to see each others activity?
I see the following options:
Option1)
Setup a Role with a specific restriction rule for the activitiy work center views assigned to the two territories or sales reps of the individual sales reps.
Option 2)
Assign both sales reps in the accoun team of the account with a specific role. In the finetuning for the activity (e.g. involved party for appointment) you can setup a party determination for that role (e.g. party copy from account team)
There is a way to do this. With roles. I created two roles. In the second role I added the activities. I gave them unrestricted rights to read. But used the same restricted rights for the write function. This role is very basic, it only lists activities. So the parent or base role, they are restricted to their customers. So they can only open their customers. They can do all they need to do. The second role gives them rights to read other activities, but it will not allow them to update them.
right. It is possible to assign differnt roles to a user and the access profile of that user is the combination of the roles assigned.
Hi Bernd, We cannot see the facet "Sales Territory" in an C4C tenant. Do you know what reason is this? The scoping is setup sucessfully. Thanks a lot Br Misher
Hi,
the sales territory facet is only available if "multiple territory" is scoped in BC, this gives you basically the ability to assign an account to more then one territory. If "single territory" is scoped the facet is not there and the territory information can be seen/maintained in the account TI header.
Regards,
Markus
Hi Bernd,
Employee Responsible and Account team are not maintained in an Account.
However, Accounts are linked to Sales Organizations in the Organizational Structure.
Can we restrict the Accounts only to Employees assigned to the respective Sales Organization in the Organizational Structure?
Hi Sandeep,
with 1508 we the access context for the account has been enhanced by the sales area (SalesOrg+Division+Distribution Channel). Hence it is now possible to assign to the employee master record the sales areas an employee is eligable for. The system will then grant access to all accounts and their contacts whit those sales areas defined in the account sales data. Please note that the organizational assignment of the employee is not relevant.
Kind regards
Bernd
Hi Bernd,
SAP has activated this "Sales Area" feature for one of our tenant . While testing this feature, below are my observations:
1) This access restriction is valid for Employees alone. Service Agents cannot have this access restriction as "Sales Data" table is not enabled. Any plans to have this feature enabled for Service Agents as well in the upcoming releases?
2) Sales Transaction data (Activities & Visits) is not having Access Context - 1015 Employee or Territory or Sales Data enabled. In this case, how are we going to restrict the transaction data based on Sales Area?
Is SAP planning to introduce 1015 access context restriction for sales transactions in the upcoming releases?
Thanks & Regards,
Sandeep
Hi Sandeep,
here my responses:
topic 1) service agents are currently not supported. Please add this topic to the ideas forum. However basically in most cases you can use employees also for not legally employeed users.
topic 2) The topic is a known topic for future backlog planning.
Hi Bernd.
If i have this
OE:
Sales Org A > Sales Office A > Sales Group A
Sales Org B > Sales Office B > Sales Group B
Accounts linked to sales area as follows:
Account A: Sales Org A, Dist. Channel A, Division A, Sales Office A, Sales Group A
Account B: Sales Org B, Dist Channel B, Division B, Sales Office B, Sales Group B
Please note that account team is not maintaned
And also an employee1 assigned to Sales group B.
My actual requirment is that my employee 1 only be able to see account A. Is there any way to restrict accounts according sales group different to territories but considering Sales area replicated from ECC?
Hope for yo to help me.
Best regards.
Hi Bernd,
I understand that C4C for Service provides only one predefined access context i.e "5-Service" for Queue and Tickets Work Center view.
I can achieve the Data Access restriction at an Org level by allowing certain Service team to View/ Edit ticket/Queue of their respective Org Unit only.
Can we as well restrict the Ticket Updates to only the Owner of ticket or the Involved parties as maintained in the Ticket?
Regards,
Rituja
Hi Rituja,
please check that by using the restriction rule "Employee Access" which limits the access restriction to be set by the user specified in the involved parties. Please note that the access is granted to a member of the involved parties independent of the role.
Kind regards
Bernd
Excellent information. Thanks!
Great ! Thanks
Hi Bernd,
Thanks for taking the time to write up this series. Its like reading an excellent mystery novel..... cant wait for the next chapter 😆 🙂
I have a scenario based question -
We have the current limitation in C4C where an employee cannot be assigned to more than 1 Org Unit.
We have a scenario where a customer and employee may have two or more sales areas assigned. Based on the access context tip you just mentioned - it seems to me that I can assign additional sales areas to employees (but not add them in the actual Sales Org)
Question is - what is the expected behavior if a sales rep needs to create an opportunity outside his org assignment, but within the additional sales areas mentioned in his employee record ? i.e.
Can the Sales rep freely create an opportunity for the customer without issues in org determination?
Do let me know?
Read this and you will find an answer... in short the sales area data is defaulted based on the intersection of what is available for the employee and account.
In a simple scenario where
Employee = Sales Area 1
Account = Sales Area 1
Then Oppty = Sales Area 1
In a complex scenario where
Employee = Sales Area 1 and Sales Area 2 and Sales Area 3
Account = Sales Area 1 and Sales Area 3
Then Oppty = Sales Area 1 or Sales Area 3 (user has to choose one of the two sales areas as there is no way to determine which one takes priority, sales area 2 is excluded as it is not part of the Account)
Sales Office vs. Org. unit C4C
Thanks for the tip Rei. I'll take a look at the blog as well.
Thanks for this super info Bernd
Hello Bernd,
In you blog, about SALES DATA, you mentioned there is a switch in the backend, this switch activates that an account w/o territory and account team member is only shown when sales area matches.
In Business Configuration, when edit the system scope, I found there is a switch about Access Context 1015; Does this switch is the one you mentioned in your blog?
Best Regards,
Allen Yao
Hi Allen,
with 1605 HF02 (23 May 2015) development has introduced the scoping option you have captured with your screenshot. This option is ment to replace the backend switch. However, the scoping option is not yet active hence the backend switch is still relevant. It is planned to activate the scoping option with 1605 HFC04 (20 June 2016). Here is what needs to be considered:
I hiope this clarifies.
Kind regards
Bernd
Thanks for your information Bernd.
Dear all,
I would ask your support in understanding if my client business requirement in terms of Accounts Access Restrictions can be covered or not.
The client has already implemented C4C Sales Module for Italy Sales Org.
For the Italian Sales Reps we have implemented Account – “Territory” Restriction Rule (Read only) –> As expected,
– in “My Accounts” view they are able to see only the accounts in the territory they are responsible
– in “All Accounts” they are able to see also accounts that are not assigned to any territory or that don’t have a territory owner responsible.
Now, the client wants to extend the C4C Sales Module also to France Sales Org.
The requirement in terms of Access Restriction is the same:
– in “My Accounts” Sales Rep (both italian and france) should be able to see only accounts in the territory the are responsible
– in “All Accounts” they must be able to see also accounts that are not assignet to any territory (or that don’t have a territory owner responsible) with the constrain that only Accounts in their Sales Org are displayed.
As suggested by one of your colleague, we tried to implement a double Business Role with different Restriction Rule (1. Territory, 2. Sales Area).
However, these were the results:
Then we tried to to implement a different combination of Business Roles Restriction Rules (1. Territory, 2. Employee)
However, these were the results:
The French Sales Reps (and thus neither the Italian) would be not more allowed to see in the “All” query Accounts:
Would be possible to satisfy such requirement allowing visibility to accounts that have not been assigned to any territory or that have not a territory owner assigned, keeping restricted visibility to only Accounts in the related Sales Org and contemporaneously on Accounts belonging to the territory the sales rep are owner?
An alternative could be the setting of a specific query, starting from standard “All”, but filtering on Sales Org and assigning separately to Italian and French Users. But for the moment we should set such query for each of the users, and it is not sustainable –> The only way to assign the query is the “Page Layout”?
Thanks in advance.
Regards,
Fabio
Hi Fabio,
please note that the access restriction is controlling the access to a set of data such as accounts at all. For example it allows you to control that a user has only access to those accounts he is assigned to in the account team or through territory, etc.
The filter in the account list (account owl) is not related to access control but provides a specific view on the set of data a user can see. If the "All Accounts" filter in the account owl is used, the user has access to all accounts he has access to. Other filter such as "My Accounts" do filter based on special filter criteria. However, the overall access is independent from that.
Kind regards
Bernd
Great info...Can we change the access context in SAP Bydesign system??? Currently we are facing issues with access restrictions since the access context is 1007 - Company so we can not give access territory/ Org unit wise....Let me know if you have any inputs regarding SAP Bydesign system. Thank you.
Hi,
actually the access context is bound to the business objects by standard definition and hence cannot be changed.
Kind regards
Bernd
Hi Bernd. Great info, tank you.
Got a question, can we restrict accounts for employees until sales group level?
Best regards
Hi Angel,
the access restriction for employees is on employee level. However, the employee access also considers the organizational assignment. For Example: A Manager can see business documents (or customers) assigned to employees of his organization.
Kind regards
Bernd
Hi Bernd,
We can see the below message in the scoping question "Remove access for unassigned data records",
"Note: Access to products without any sales data will still be granted independent of this scope selection"
But in our scenario, users don't want to see the products if the sales data is not assigned, could you please let us know do we have any other option to restrict the unassigned products to users.
Thank you in Advance...!
Regards,
Vignesh Karuppasamy
Hi Vignesh,
Actually for products you have to maintain the sales data to enable the restriction settings.
Kind regards
Bernd
Hi Bernd,
We are using the restriction of "Service unit of Employee" for Tickets work-center. As expected the restriction is working fine and returns the Tickets from the Service Unit of Employee.
However if a Ticket from different Service Unit is depersonalised, then this depersonalised ticket is visible for all the users irrespective of restriction Rule.
Please let us know how can we restrict the visibility of depersonalised tickets.
Thank you in Advance...!
Best Regards,
Vignesh Karuppasamy.
Hi Vignesh,
I am not sure what exactly you mean with "depersonalize". In case you have removed all access restriction relevant content (employee assignments, territories, service untis) from the ticket, the system is not able to determine a restriction for the ticket and hence it is accessible to all users (aka homeless object instance). In the scoping you find a scoping option where you can make those "homeless" object instances inaccessible. This option works for a number of business object (e.g. accounts) and might also help in your situation:
you also find more details on this topic in my blog "Access Control Management: Access restrictions explained – Access Context" https://blogs.sap.com/2015/07/15/access-control-management-access-restrictions-explained-access-context/
Kind regards
Bernd
Hi Bernd,
thank you for the great blog!
We want to just restrict and make the accounts that are automatically created by the C4C system for Org Units invisible to our users. Currently we dont have any restrictions for accounts.
I thought this could be implemented via a Sales Data Restriction Rule (no. 5). My first thought was to create a kind of blacklist to assign the 10 accounts for Org Units a special Sales Org, and restrict on this Sales Org. Then, I realized that blacklists are not possible in context of Sales Data restiction, just white liste in the employee master data (because the 99-special restriction rule cannot be used on sales data).
My problem now is: We have a lot of accounts with no sales data and an owner. How can I make these visible to everybody? Currently the scoping question for compability mode 1015 are not active and the scoping question for homeless accounts restriction is as well not active. So I have no issue with accounts that has no sales data and no owner - these are visible. But accounts with no sales data and an owner - these are currenlty not visible but I would like to not restrict those.
Do you have a tip for me?
Thanks a lot!
Best regards, Deborah
Hi Deborah,
when you create an org unit and flag it as company then C4C automatically creates an account. This account is then used as involved party in quotes in the role “Seller”.
As there are no further data available on these accounts with an associated org unit it is not possible to use access restriction rules in order to make only those specific accounts not visible for users.
One solution to make those accounts invisible is to organize the query “All Accounts” by excluding the accounts with an existing associated org unit. There is a field “Associated Org Unit Exists” which can be made visible as filter criteria. You can then exclude those accounts and save the query as “All Accounts”.
I hope this could be a solution for your requirement.
Cheers,
Daniel
Hi Bernd,
we are working on a new Implementation of C/4 Sales for a Customer in Hamburg. Sales Manager are assigned to Sales units and territories.
Teams are allowed to cross sell within the Sales Organizations.
When selling to another Sales Unit, they keep their own territory in the Objects (Lead, Opp, Quote, Contract) but change the Sales unit they are selling for.
Now the managers of the teams need to see evertying of their own territory and below (which is standard) but also what has happened in their Sales Unit.
This also reflects on reporting.
The issue is, I can´t restrict authorizations on Sales units, only to Sales Data including Organization, Dist.. Channel, and division but that is to high. We have Units (not marked as Organization) below, where managers are attached to.
How can I allow Managers to see everything which has been created in their Sales Unit?
Of course the Organzational structure is given by the backend and not changable to our sales structural needs.
Also I can´t do automatic Partner determination on Sales Units to add the manager to sales team and enable him to see the object with the authorization rule sales team.
Thanks for any hints.
Best Regards,
Cem