- 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
- 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.
Please note: In some cases it might happen that an account is initially be 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 might make sense to assign ta default territory, a default employee or a default sales area to that account. With 1702 a scoping option has been introduced which 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”.
Please note that access restriction by sales area is only effective for accounts with either an account team member or a territory assigned. This default behavior can be changed by a switch in the scoping. This switch activates that an account w/o territory and account team member is only shown when the sales area matches. The switch is necessary to prevent an inconsistent change with the introduction of the new access context. So please create a ticket when you need to use this feature to request the activation.
With 1605 HFC02 (23 May 2016) development has prepared the back end switch to get replaced by a scoping option. 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”.
As of 1605 HFC04 (20 June 2016) has been set active. Here is what needs to be considered:
- by default the scoping option is checked –> compatibility mode
- In order to achieve the same behavior as with the back end switch, the scoping option needs to be unchecked.
- Development has uncheck the scoping option for those customers which have set the back end switch through the ticket process. With this action the scoping option will be set in sync with the back end switch for the relevant customers.
- With 1605 HFC04 (20 June 2016) the scoping option is active. With this change the back end switch will no longer be considered to control the access behavior
- Creating tickets is not longer necessary as administrator can now use the scoping option.
Read/Write access can be restricted on Work Center View (Business Object) level.
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.