Name: Understanding Access Context in SAP Sales Cloud
Uploaded: 2020-10-20
Duration: 353 s
Description: This video explains the concept of Access Context in SAP Sales Cloud and how it relates to Business Objects and Custom Business Objects.

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><div>This video explains the concept of Access Context in SAP Sales Cloud and how it relates to Business Objects and Custom Business Objects.<br></div></div></div></div>

Understanding Access Context in SAP Sales Cloud

Hello, I'm Amy. In this video, you'll learn the concept of access, context and how it relates to business objects and custom business objects in SAP Sales Cloud. Each object is controlled by the access context. Access context is a characteristic of the work's interview and the business object. For example, the work's interview account has the access context 1015 based on employee or territory account and sales data. The same access context 1015 is also relevant for other business objects like opportunities leads, sales quotes and sales orders. Other business objects such as the product, have different access contexts assigned. The access context is defined by the standard set up of the business object, and cannot be changed or enhanced. I'll demonstrate this under the Access Restrictions tab. I see the Access Context column. I can filter by our example 1015, and I already see that several objects share the same access context based on employee territory, account and sales data. However, not all of them. If I search product, I can see access context 2001 based on the sales organization distribution channel. And if I look at the product category, there is no access context. This implies that if the access context is undefined for a work center view or business object, a distinct instance based access control set up is not possible for that particular entity. So how can I explain access context in our example 1015 related to accounts. This implies that the sales representative can access the relevant account if any of the following criteria are met for employees, meaning all in both parties. The sales representative has access to all accounts where they are a member of the account team. For a territory, the sales representative has access to all accounts assigned to a territory in which they are a team member. Note that accounts assigned to sub territories of the relevant structure are also accessible. Sales data is comprised of combinations of sales organizations, distribution channels and divisions. The sales representative has access to all accounts assigned to a valid combination of sales data between employee and account. Employee sales data can be maintained in the employee Master. This can be performed independently of the actual organizational assignment. If an employee is assigned to an organizational unit without an assigned distribution channel or division, that employee will not be restricted from the account or sales documents based on their sales data. Currently, there is a limit set for 1000 records by account team and by territory team. If this limit is exceeded, the related transactions would not be visible and this is communicated with a warning message. If you would like to grant users access to all transactions related to their accounts by using multi territory assignments to accounts, there is a scoping question which asks do you want to use all territories assigned to an account to grant access to its transactions? This can become relevant if most of your users exceed the 1000 accounts limit. For customers who started to use the system prior to the introduction of the sales area. In the access context, a scoping option was introduced to ensure compatibility with the prior access behavior. If you want to restrict accounts and transactions by sales area, make sure the question is deselected. In some cases, an account is initially created and has no access restriction. Relevant data maintained, such as directly assigned employee or a territory. In this case, the system is designed to be access tolerant and it provides access to the objects instance by default. You can configure the access to business objects that do not yet contain any access context, such as a territory, sales area, or an employee assignment. Without the related business scoping, all users can access these data records. To avoid this, only users with unrestricted access can view these business objects. There is an exception for products. Products without any sales. Organization assignments can be accessed by all users independent of a restriction for the product record. So what happens in the case of custom developed business objects? Typically, custom business objects are created through development with the support of SAP Cloud Applications Studio. When it comes to the restrictions of custom business objects, there are two possibilities. Access control context can be inherited from a standard business object through association, or it is also possible to define a custom business object. Specific access control context.