Name: Understanding Access Management and Additional Functionalities in SAP Sales Cloud Part 1
Uploaded: 2020-11-6
Duration: 629 s
Description: This video explores the various functionalities that impact access rights used in SAP Sales Cloud. You'll learn about Access Forwarding, Delegates, and Report Assignments to Business Roles functionalities.

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><div><div>This video explores the various functionalities that impact access rights used in SAP Sales Cloud. You'll learn about Access Forwarding, Delegates, and Report Assignments to Business Roles functionalities.<br></div></div></div>

Understanding Access Management and Additional Functionalities in SAP Sales Cloud Part 1

Hello, my name is Minnie. This video explores access, forwarding, delegates and report assignments to business roles, functionalities that impact access rights used in SAP Sales Cloud. I'll begin with access forwarding. Access forwarding is an exceptional access control behavior is implemented for several business objects like accounts, contacts, leaves, opportunities, and others. So how does it work? The last business user that made a change to a business object is added to the access control list. The access control list is a structure attached to the business object by which the actual access is being determined. As the last business user that apply to change is added to the access control list, that user has access to the object instance for a while. This functionality addresses two main scenarios. As an example, let's say Geral, who's a sales rep, has restrictions to account and she's only the ones with the sales organization he's a part of. However, he comes across a valuable prospect for his colleague as part of a different sales organization. As a result, the sales rep decides to create the prospect, although out of his usual access rights use an access forwarding. The sales rep temporarily has access to create this record with edit permissions. Another scenario that benefits from access forwarding allows users to revert changes that may occur accidentally, which could lead to the loss of the access right to that business object. You might ask how long the access is granted. The access control list retains the last user. If an object is created or a change has been made by mistake. The user that saved this has access to revert it until another user is making a change for the same business object. It's noted that for business partners, there's an additional exception. The entry of the last user into the access control list is valid until the end of the day. This applies to a user who creates or edits an account with access until the end of the day only. Even if no other user had applied changes to that account afterwards, let's see this behavior in the system for holistic view. I'll check the settings for Gerald's business role as a sales rep. I see that Gerald has a restriction rule based on employee territory account and sales data. I'll log in as Gerald and navigate to account works in a view. Here I see that Gerald, owner of the no account. I'll further inspect the details. And Gerald as part of the account team as the owner. Since I have rights to delete this assignment, I'll click on the remove icon and save the changes. I'll click the refresh icon. Here I see that Gerald's account is not listed under the query My account. However, if I change the query to all accounts, I can still find the new account. Although Gerald is no longer a team member and the account has no territory determined. This scenario is handled by access forwarding to show that Gerald so has access to that customer. To confirm the behavior, I have the option to check the next day to see that the account is not assessable anymore, or apply change to this account with different business users. I'll move forward to log in as Gerald. I'll click on Customer and Accounts. Next I'll change the query to all accounts. Here I'll search by new account from Gerald's perspective. The account is no longer accessible. SAP Sales Cloud has a delegate functionality. This feature is used when users are out of the office in their substitutes. Need to be able to continue their work. This also requires a substitution to get the same access rights for the period they're substituting for their colleagues. The delegate works into view as assigned to access context 2008 org unit. As an example, it's possible to restrict access to employees at their own organizational unit in case of access rights issues. Always check to see if there are any delegate entries active for the users. Next, I'll demo this functionality based on two scenarios. I'll begin with the setup. Daniella Silber is a sales manager and has access to Gerald, Peter and Sandra's accounts due to the existing setup. However, Gerald, Peter and Sandra can't see each other's accounts. Let's see what happens if Peter is going on leave and using the delegate function to provide access to Daniella Silber. Additionally, Daniella Silber is going on leave as well and decides to appoint Gerald as a substitute. I'm logged in as Daniella Silber, who has access rights for the entire team. Including Peter. And Gerald's accounts. Next, I'll switch to Gerald for you to show only his accounts. In the once without access restriction determination. The same applies for Peters accounts. As previously mentioned, the delegates are set up. Peter is delegating to Daniella, and Daniella is delegating to Gerald. Note and assigning delegate. The user can choose specific work centers that substitutes have access to. Next, I log in as Gerald to see all the accounts that Daniella has access to, including Peter's account. Since Daniella previously had access to these accounts independent of the delegate assignment between Peter and Daniella. Now let's see what happens if Peter is going on vacation and delegating this account to Sandra. But Sandra is taking a leave of absence and appoints her account to Gerald. Keep in mind that due to access restrictions, none of the sales reps have access to other accounts. By logging in as Sandra More, her settings will look like this. The delegation process falls under the employee responsibility. Peter, prior to going on vacation, maintained his delegate as Sandra. Sandra has maintained her delegate as Gerald, but the relevant time frames. Here I'm logged in as Gerald. You can easily see that Gerald has access to Sandra's account based on the delegate function, but not to Peter's accounts. This underlines the fact that the delegated access rights aren't further inherited. Running a report also requires the right access settings for a user in order to provide access for a report to the business user. I'll cover two steps. Assign the report to work centers. Set access for the report to require business roles in the configuration. The administrator can specify whether the reports need to be assigned to business roles if that indicator is set. The report in addition, needs to be assigned to the business role. To make that report available for the business user. Note that report data follows access contact roles, whether the option for business roles is enabled or not. The option for business roles is an additional restriction, which can be used to restrict seeing the report in the analysis policy data shown during report execution as following the restrictions from access context only. You'll see in the demo and the report, the header line shows the access context. The access context of the report is derived from the data source. Other report. The access context of the data source is coming from the business object. The data source relates to next and the detail left to the report. The work center views are listed also with their access context. The access restrictions for a report are inherited from the works in a view. The report is assigned to. When the access context of the work center view matches with the access context of the report, the line is flagged with the green checkmark. The report only shows the data the user is allowed access to. If a report is assigned to a work center, view where the access context doesn't match the system indicated it with a red exclamation mark. Here I'm logged in as an administrator. I'll navigate to the Business Analytics work center and choose a design report. Works in a view. Here I see the list of all standard and enhanced reports, and if a report is assigned unassigned or hidden, I'll use the search function to narrow the reports list by account. For this example, I'll use my accounts visit and click on the top right corner and select assign. Here I can assign the report to the work centers I need. I'll click close and return to the overview page. From the general tab, actually access context 1016. By looking at the assigned work centers, I have a good understanding of where the report is assigned. The next step is to assign the report to the relevant business roles. Navigate to the top right menu options. Select Set Access to see the list of active business roles. Here I can expand or reduce the reports with other business roles. Thank you for watching.