Skip to Content
  1. Basics of access control and business roles
  2. Access Control Management: Access restrictions explained  – Access Context (this blog)
  3. Access Control Management: Access restrictions explained  – Restriction Rules
  4. Access Control Management Example: Global versus local admin
  5. Access Control Management Example: Access forwarding
  6. How to analyze access control issues
  7. 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.  

 

0200_AccessContext.png

 

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.

 

0201_AccountTeam.png

 

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!

0202_TerritoryTeam.png

 

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.

 

0203_SalesData.png

0204_EmployeeSalesArea.png

 

Read/Write access can be restricted on Work Center View (Business Object) level. 

 

Question:

 

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. 

 

 

To report this post you need to login first.

29 Comments

You must be Logged on to comment or reply to a post.

  1. Mark D. Huelsman

    We create territories based on zip codes. For this question we have two person calling on a couple zip codes. We have created two territories as we have sales and service sales persons calling on a block of zip codes. There is overlap. So a sales person has zip 12345 and 123456 – Territory 1. The service person has zip 123456 and 123457 – Territory 2.   So for accounts in zip 12346 we would like both persons to see each others activity. Is that possible?

    (0) 
    1. Bernd Fleddermann Post author

      Hi mark,

      yes, the assignment of multiple territories is possible. This needs to be activated in the Business Confuguration (Work Center: Business Confirguration –> Implementation Projects –> Edit Project Scope; Questions –> Sales –> Account and Activity Management Territory Managemnt: “Do you want to assiggn an account to more than one territory”)
      With the activation of multiple territories the territories are shown in the account in an own facet “Sales Territories”.

      I hope that helps

      Kind regards

      Bernd

      (0) 
      1. Mark D. Huelsman

        We have multiple territories configured. That is working fine. The account has two territories. Each rep can see the accounts so that works. The issue is we would want each other to see each others appointments and other activities. Just so they have awareness of the activity at the customer. They sell different things to the customer, one new equipment, the other service and parts.   Is there any thing in the roles or other areas that would allow them to see each others activity?

        (0) 
        1. Bernd Fleddermann Post author

          I see the following options:

          Option1)
          Setup a Role with a specific restriction rule for the activitiy work center views assigned to the two territories or sales reps of the individual sales reps.

          Option 2)
          Assign both sales reps in the accoun team of the account with a specific role. In the finetuning for the activity (e.g. involved party for appointment) you can setup a party determination for that role (e.g. party copy from account team)

          17-09-2015 15-45-47.png

          (0) 
          1. Mark D. Huelsman

            There is a way to do this. With roles.  I created two roles. In the second role I added the activities. I gave them unrestricted rights to read. But used the same restricted rights for the write function. This role is very basic, it only lists activities. So the parent or base role, they are restricted to their customers. So they can only open their customers. They can do all they need to do. The second role gives them rights to read other activities, but it will not allow them to update them. Cross Territory.JPG

            (0) 
      2. Misher Liu

        Hi Bernd, We cannot see the facet “Sales Territory” in an C4C tenant. Do you know what reason is this? The scoping is setup sucessfully. Thanks a lot Br Misher

        (0) 
        1. Markus Penn

          Hi,

          the sales territory facet is only available if “multiple territory” is scoped in BC, this gives you basically the ability to assign an account to more then one territory. If “single territory” is scoped the facet is not there and the territory information can be seen/maintained in the account TI header.

          Regards,

          Markus

          (0) 
  2. Sandeep Kedarisetty

    Hi Bernd,

    Employee Responsible and Account team are not maintained in an Account.
    However, Accounts are linked to Sales Organizations in the Organizational Structure.

    Can we restrict the Accounts only to Employees assigned to the respective Sales Organization in the Organizational Structure?

    (0) 
    1. Bernd Fleddermann Post author

      Hi Sandeep,

      with 1508 we the access context for the account has been enhanced by the sales area (SalesOrg+Division+Distribution Channel). Hence it is now possible to assign to the employee master record the sales areas an employee is eligable for. The system will then grant access to all accounts and their contacts whit those sales areas defined in the account sales data. Please note that the organizational assignment of the employee is not relevant.

      Kind regards

      Bernd

      (0) 
      1. Sandeep Kedarisetty

        Hi Bernd,

        SAP has activated this “Sales Area” feature for one of our tenant . While testing this feature, below are my observations:

        1) This access restriction is valid for Employees alone. Service Agents cannot have this access restriction as “Sales Data” table is not enabled. Any plans to have this feature enabled for Service Agents as well in the upcoming releases?

        2) Sales Transaction data (Activities & Visits) is not having Access Context – 1015 Employee or Territory or Sales Data enabled. In this case, how are we going to restrict the transaction data based on Sales Area?

        Is SAP planning to introduce 1015 access context restriction for sales transactions in the upcoming releases?

        Thanks & Regards,

        SandeepCapture.JPG

        (0) 
        1. Bernd Fleddermann Post author

          Hi Sandeep,

          here my responses:

          topic 1) service agents are currently not supported. Please add this topic to the ideas forum. However basically in most cases you can use employees also for not legally employeed users.

          topic 2) The topic is a known topic for future backlog  planning.

          (0) 
  3. Rituja Rai

    Hi Bernd,

    I understand that C4C for Service provides only one predefined access context i.e “5-Service” for Queue and Tickets Work Center view.

    I can achieve the Data Access restriction at an Org level by allowing certain Service team to View/ Edit ticket/Queue of their respective Org Unit only.

    Can we as well restrict the Ticket Updates to only the Owner of ticket or the Involved parties  as maintained in the Ticket?

    Regards,

    Rituja

    (0) 
    1. Bernd Fleddermann Post author

      Hi Rituja,

      please check that by using the restriction rule “Employee Access” which limits the access restriction to be set by the user specified in the involved parties. Please note that the access is granted to a member of the involved parties independent of the role.

      Kind regards

      Bernd

      (0) 
  4. Prajith Nair

    Hi Bernd,

    Thanks for taking the time to write up this series. Its like reading an excellent mystery novel….. cant wait for the next chapter 😆 🙂

    I have a scenario based question –

    We have the current limitation in C4C where an employee cannot be assigned to more than 1 Org Unit.

    We have a scenario where a customer and employee may have two or more sales areas assigned. Based on the access context tip you just mentioned – it seems to me that I can assign additional sales areas to employees (but not add them in the actual Sales Org)

    Question is – what is the expected behavior if a sales rep needs to create an opportunity outside his org assignment, but within the additional sales areas mentioned in his employee record ? i.e.

    • Employee assigned to Org Unit 1 – Sales Area 1
    • Customer Assigned to Sales area 2
    • Employee now assigned to Sales area 2 in the employee master
    • Employee attempts to create opportunity for Customer assigned in Sales area 2

    Can the Sales rep freely create an opportunity for the customer without issues in org determination?

    Do let me know?

    (0) 
    1. Rei Kasai

      Read this and you will find an answer… in short the sales area data is defaulted based on the intersection of what is available for the employee and account.

      In a simple scenario where

      Employee = Sales Area 1

      Account = Sales Area 1

      Then Oppty = Sales Area 1

      In a complex scenario where

      Employee = Sales Area 1 and Sales Area 2 and Sales Area 3

      Account = Sales Area 1 and Sales Area 3

      Then Oppty = Sales Area 1 or Sales Area 3 (user has to choose one of the two sales areas as there is no way to determine which one takes priority, sales area 2 is excluded as it is not part of the Account)

      Sales Office vs. Org. unit C4C

      (0) 
  5. Allen Yao

    Hello Bernd,

    In you blog, about SALES DATA, you mentioned there is a switch in the backend, this switch activates that an account w/o territory and account team member is only shown when sales area matches.

    In Business Configuration, when edit the system scope, I found there is a switch about Access Context 1015; Does this switch is the one you mentioned in your blog?

    /wp-content/uploads/2016/05/bc_958584.jpg

    Best Regards,

    Allen Yao

    (0) 
    1. Bernd Fleddermann Post author

      Hi Allen,

      with 1605 HF02 (23 May 2015) development has introduced the scoping option you have captured with your screenshot. This option is ment to replace the backend switch. However, the scoping option is not yet active hence the backend switch is still relevant. It is planned to activate the scoping option with 1605 HFC04 (20 June 2016). Here is what needs to be considered:

      • In order to achieve the same behavior as with the backend switch, the scoping option needs to be unchecked.
      • Within the next days development will uncheck the scoping option for those customers which have set the backend switch through ticket. With this action the scoping option will be set in sync with the backend switch for the relevant customers.
      • With 1605 HFC04 (20 June 2016) it is planned to activate the scoping option. With this change the backend switch will no longer be considered.
      • Customers who need to get the access control behavior adjusted before 1605 HFC04 still need to create a ticket
      • Customers who can wait to get the scoping option adjusted until 1605 HFC04 nut already want to prepare the setting can set the scoping option now and wait until it is active with HFC04.

      I hiope this clarifies.

      Kind regards

      Bernd

      (0) 
  6. Pierfabio Teresi

    Dear all,
    I would ask your support in understanding if my client business requirement in terms of Accounts Access Restrictions can be covered or not.

    The client has already implemented C4C Sales Module for Italy Sales Org.
    For the Italian Sales Reps we have implemented Account – “Territory” Restriction Rule (Read only) –> As expected,
    – in “My Accounts” view they are able to see only the accounts in the territory they are responsible
    – in “All Accounts” they are able to see also accounts that are not assigned to any territory or that don’t have a territory owner responsible.

    Now, the client wants to extend the C4C Sales Module also to France Sales Org.
    The requirement in terms of Access Restriction is the same:
    – in “My Accounts” Sales Rep (both italian and france) should be able to see only accounts in the territory the are responsible
    – in “All Accounts” they must be able to see also accounts that are not assignet to any territory (or that don’t have a territory owner responsible) with the constrain that only Accounts in their Sales Org are displayed.

    As suggested by one of your colleague, we tried to implement a double Business Role with different Restriction Rule (1. Territory, 2. Sales Area).
    However, these were the results:

    • the Sales Org Restriction Rule OVERRIDES the Territory Restriction:  A FRENCH Sales Rep, in the “ALL Accounts” view is able to see also FRENCH Accounts belonging to another territory with different Territory Owner

    Then we tried to to implement a different combination of Business Roles Restriction Rules (1. Territory, 2. Employee)
    However, these were the results:

    The French Sales Reps (and thus neither the Italian) would be not more allowed to see in the “All” query Accounts:

    • Neither Accounts with no Territory Owner assigned
    • Neither accounts assigned to any Territory

    Would be possible to satisfy such requirement allowing visibility to accounts that have not been assigned to any territory or that have not a territory owner assigned, keeping restricted visibility to only Accounts in the related Sales Org and contemporaneously on Accounts belonging to the territory the sales rep are owner?

    An alternative could be the setting of a specific query, starting from standard “All”, but filtering on Sales Org and assigning separately to Italian and French Users. But for the moment we should set such query for each of the users, and it is not sustainable –> The only way to assign the query is the “Page Layout”?

    Thanks in advance.
    Regards,
    Fabio

    (0) 
    1. Bernd Fleddermann Post author

      Hi Fabio,
      please note that the access restriction is controlling the access to a set of data such as accounts at all.  For example it allows you to control that a user has only access to those accounts he is assigned to in the account team or through territory, etc.
      The filter in the account list (account owl) is not related to access control but provides a specific view on the set of data a user can see. If the “All Accounts” filter in the account owl is used, the user has access to all accounts he has access to. Other filter such as “My Accounts” do filter based on special filter criteria. However, the overall access is independent from that.
      Kind regards
      Bernd

      (0) 
  7. Aruna Thakar

    Great info…Can we change the access context in SAP Bydesign system??? Currently we are facing issues with access restrictions since the access context is 1007 – Company so we can not give access territory/ Org unit wise….Let me know if you have any inputs regarding SAP Bydesign system. Thank you. 

    (0) 

Leave a Reply