Overview

When you work with SAP Sales Cloud and SAP Service Cloud solution, you want to be able to manage access control for all your user. 

This article will give you an overview of the SAP Sales Cloud and SAP Service Cloud solution access control management features with a focus on access context concept.

Table of Contents

Access Context

In the previous article, you learned 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 image, 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. However, for others, 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. Therefore, the access control capabilities for a certain Business Object works in the defined structure of the access context.

This implies that if the access context is undefined for a work center view/Business Object, a distinct instance base access control setup is not possible for that particular entity.

For a custom Business Object created with the SAP Cloud Application Studio, access control can be inherited from a standard Business Object through association. In addition, it is also possible to define a custom Business Object specific access control context related to employees or territories.  

Access Context - Example for the Account Scenario

The work center view “Accounts” is assigned to the access context 1015 (Employee or Territory or Sales Data).

This implies that access to an account can only be controlled based on the following criteria:

 

• Employees directly assigned in the account team.
  
  In this case, your users have access to all accounts where they are a member of the account team (independent of the role assigned) or their managers have access to all accounts of employees of the functional unit (organization) for which they are assigned as a manager.
  
  
  
  
  

• Territory Team
  Your users have access to all accounts which are assigned to a territory in which they are a member.  Accounts assigned to territories which are sub-territories of their territory are also accessible. 
  

  Note: The work center territories, where the territories can be maintained, works with a different access context –1010 Employee.

  
  

  
  
  

• Sales Data
  Your users have access to all accounts which are assigned to a sales area in which they are eligible. The assignment of relevant employee sales areas can be maintained in the employee master. This can be done independently of the actual organizational assignment.
  

  
  

  If you started using the system prior to the introduction of a sales area in the access context, note that a scoping option was introduced to ensure compatibility with the previous access behavior.

  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 version "1605", the compatibility mode is not active by default; an account without a territory and an account team member is accessible only when the sales area matches.

  The 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, an account could be created initially without a direct employee or territory assignment and hence has no relevant access restriction data maintained.

In this situation, it is either a "homeless" object instance or includes unassigned data records. Therefore, the system is unable to determine how to restrict access for a certain user on this account. 

The system is designed to provide anyhow access to the object instance by default and to react "access tolerant". This behavior is also relevant to other Business Objects.

If this is undesired, it is possible to change the default access behavior of the system in scoping. This option allows the hiding of object instances without any restrictive content (that is, unassigned data records).

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 the sales area data maintained.

As a recap of the above, consider the following scenario for a fictional account Widgets Inc.:

For Widgets Inc., Violet is assigned as the owner of the account. This means that she is the designated employee who is responsible for that account. Violet’s business role provides access context to accounts by the "Employees" criteria.

More in detail 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 the access context criteria outweigh her role as "employee responsible". Even though she is the employee responsible, her access restriction settings in the role assigned to her, only provide access to accounts that are owned by Peter. 

Conclusion

This article introduced you to the concept of access context. Now, you know what to consider when you want to restrict access to your business roles.

The article below will continue guiding you through the access control management feature and will focus on the restriction rules.

Access Control Management – Restriction Rules