Name: Understanding Access Restrictions in SAP Sales Cloud
Uploaded: 2020-10-20
Duration: 722 s
Description: This video explains the concept of Access Restrictions and how access rights can be manipulated to suit unique business needs.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div>This video explains the concept of Access Restrictions and how access rights can be manipulated to suit unique business needs.</div>

Understanding Access Restrictions in SAP Sales Cloud

Hello, I'm Amy. In this video, you'll learn the concept of access restrictions and how access rights can be manipulated to suit your business needs. When setting up a role, it is recommended to use access restriction rules. This might not be possible for all use cases, but using restriction rules can significantly reduce the number of different business roles. As the same rule can be used for users of different organizations, territories and more. The main benefit of using restriction rules is reduced maintenance and administration effort. I'll demonstrate this. The restriction rule can be maintained in the access restriction facet on an individual works interview level. For example, if I take the account works interview, I can edit the access of read and write for the object. I'll click in the read access column on the drop down value and select restricted. This is enabled at the bottom of the Restriction Rules page. If I expand the restriction rule drop down values, I'll see all the available restriction rules for the access context. 1015 employee or territory or sales data, other works, interviews or business objects which are assigned to different access contexts will provide a different set of restriction rules. The restriction rules are defined in the system and cannot be changed or extended. A small exception is rule 99, which I'll explain later in the video. I'm going to restrict the access for business roles sales representative users to read and write accounts only with the recommended restriction rule based on territory and employee. Finally, I'll save the changes. How does the system translate the access restrictions for the individual business users? I'll demonstrate. I'm logged in as Gerald Weber, who is a sales representative and a territory team member for the Germany territory. I'll expand the work center customers and click accounts. I've defaulted to the query my account and I can see eight records. Gerald is the owner of some of the records, and others just fall under his territory. Assignment. However, if I change the query to see all the accounts, I can see the entire list of accounts which totals 237. I'll show you what happens if I apply the restriction rule that I just discussed. I'll log in as the local administrator and edit the sales representative business role that Gerald has assigned against his business user for the works interview accounts. I'll click on the Read Access dropdown and select restricted. Notice that the restriction rule based on territory and employee defaults, and includes a short description. I'll click save and I'm prompted with a pop up notification to confirm the user update. Alternatively, I can click on assigned users and update users. I would need to update the users if I want to see the effect of this change immediately after I apply them. Now I can check the view from Gerald's perspective. I'll log in as Gerald and follow the same steps as before. If I filter by all the accounts, since there is the restriction rule in place, the total number is down from 237 to only 44. Records that meet the restriction criteria. As I just demonstrated, the access comes from a combination of the employee access contacts and accounts where the employee is directly assigned as an account team member, and the territory part of the access contacts and or accounts which are assigned to a territory or separate Uri that the employee is a member of. If you are working with several levels of territory structure and you notice that the accounts belonging to accept territory are not listed, you can check the include Sub Territories checkbox. This checkbox is not selected in the default My account queries. Also, you can enable through adaptation the Include Sub territories checkbox since it's hidden by default. Keep in mind that these are dynamically generated access rights. Dynamically means that a change of Gerald's territory assignment will lead to a change of his territory related access rights. In other words, if Gerald moves to a different territory, he will have access to the relevant accounts from his new territory. Depending on each company's business process, it might happen that a sales representative needs to access an account in different stages of its life cycle. What would happen if the account has no access yet related to the date maintained? I'll demonstrate. I'm logged into SAP Sales Cloud as a sales representative. I'll go to the accounts works and review and search for the new account. I'll open the object details. Here I have a new account, and I can see that there are no employees or any account team members. No territory was derived and no sales data has been determined or maintained under the sales data tab for this account. Why can I see the account since there are no restriction rules in place? The system is designed to provide access to the object instance by default. This behavior is also relevant for other business objects. However, if you want to have a different behavior, this scoping question under User and Access management should be addressed. The question is do you want in general to restrict access data records that do not contain any access relevant content? Pay attention to how 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 maintains sales area data only. There are several restriction rules available based on different business objects. Now let's discuss the My Workforce Restriction rule. This restriction rule is applicable for complex matrix organizations based on relationships that are different than the organizational structure. It is currently available for the following access contexts 1015 sales quote sales order lead opportunity account and 1016 business activity email appointment visit route phone call tasks. How does this work? The My Workforce Restriction rule considers the employee relationships. Supervises and works for Bureau two six for access control. This enables the set up of an additional hierarchical relationship structure between employees, independent of the organizational structure and its assignments. If you would like to use this restriction rule, please note that the relationship by default is inactive and needs to be activated in the fine tuning under General Business Partners and then relationships. Once we have the relationship activated while logged in as an administrator, I can go to the desired business role and sales representative and apply the restriction rule called my workforce. Any changes should be saved with the business users for the updates to take effect next. Relationships should be built between the employees. There are multiple ways to create and maintain relationships. In this demonstration, I'll apply the change manually. First, I'll go to the work center people and select the Employee Works interview. Here I'll search for the sales representative, Gerald. I'll open the detailed view of the record and navigate to the relationship tab. I'll click add and select the newly activated relationship type supervises. Now I'll assign the relationship to another employee Clemens K. Now I'll click Add and save. I'll close Gerald's employee record and check Clemens case record to be sure this relationship is reflected in his employee record. I'll search for Clemens K, open the record. And under the relationship tab, I see the type works for and the link to Gerald. Since the settings are finished, I can look in the system from Gerald's perspective. I'm logged in as Gerald now, so I'll go to the accounts works interview and filter by all accounts. Next I'll search by Clemens KS account, since I know that he's the owner of only one account. I'll open the accounts details and I can easily see that Gerald is not mentioned as a team member. However, since Clemens K is the owner of the account and we have maintained the relationship between Gerald and Clemens, K Gerald can access this account based on the restriction rule. My work force if you encounter difficulties in reproducing this behavior. Please note in order to have the new relationship assignment also reflected in the actual access control setting, the role needs to be updated following the sequence. Business role assigned users update user. Alternatively, a background job is running daily at midnight to automatically update the user to any new relationships. If none of the other restriction rules can be used in a scenario, you can consider defining a specific restriction using rule 99. In general, you should avoid using rule 99 if possible. But I'll demonstrate how to use the rule in case it's needed. I'll go directly in the system for demonstration. I'm logged in as an administrator and I'm editing the business role sales rep. I'll go to our account work center view. Now I'll select read access restriction and then choose the restriction rule 99. This opens additional setting options at the bottom of the screen based on employee sales, organization and territory. Once I expand the sales organization, I can see the full list defined in our organizational structure and on the right hand side column I can apply, read and write restriction by clicking the checkboxes that correspond to what I want. As an example, you might want to apply restrictions on some historic structures. If you want to grant the user access data that is no longer in use, choose historic restrictions. For example, in the territory indirect sales U.S. select or deselect the corresponding checkbox in the Read Access or Write Access column. And then save your changes. Please note that the selections using access Group ID employees applies to the restriction for employees only, not on the selected organizational unit itself, and also selections using access Group ID referring to the sales data for product. Applies the restriction only if it's selected at the sub level and division level. Thank you for watching.