CRM and CX Blogs by Members
Find insights on SAP customer relationship management and customer experience products in blog posts from community members. Post your own perspective today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

SAP Cloud for Customer (C4C) like so many other products by SAP has complicated, multi-functional screens; in C4C these screens are called Work Centre Views. Therefore, as with other products by SAP, there is a proper method to control and restrict access to certain screens in C4C. This method is based on the notion defining the authorization access of the user at the screen level with controls over his actions within the screen and at the specific level of data restrictions based on the hierarchy in the Organization by which the user is located.

In short, we have two levels of restricting a user in C4C. The first is a broad stroke, restrict the user from accessing certain views in a work centre. The second is a more controlled, refined restriction of certain data within an authorized view in a work centre based on the user’s position within the organization, as detailed in the access context of the authorized view. This position is usually reflected in a Sales Org Chart or Sales Territory hierarchy and the users have a very well-defined job scope to match the required restrictions.

Restrictions based on Work Centre Views within a Role

Restrictions at the level of Access Context based on Org Structure within a Role


Basics of Business Roles

Business Users in C4C can be activated and be given authorization access based on specific work centres individually or through a set of work centres that come in a Business Role. Such a role is meant to package together the access restrictions based on a fixed business functionality within C4C that a user performs when assigned said role. Therefore, the idea of a business role is to contain the authorizations required by a user to perform a specific role in C4C. As such, there is great advantage to having multiple business roles created within one C4C tenant and each role is targeted towards a group of users that perform similar tasks within the organization hierarchy.

First advantage is that managing the access rights within the C4C tenant becomes more structured and orderly. This is because any change in granting access rights to the group of users assigned to a particular role becomes streamlined and systematic. Secondly, changes in a role can be tracked and thus there is a traceability towards the access restrictions given to a user over a certain period of time. This allows for better governance of the security of the C4C tenant.

Changes to a Role is tracked in Change History tab

Apart from Work Centre Views and Access Context restrictions, there are other restrictions such as Page layouts within a View that can be restricted via UI Switches and also Fields and Actions within a View that can be restricted via Fields & Actions. These restrictions are meant to allow for greater flexibility in maintaining a control over the view of the users within C4C.


Concept of Access Restrictions via Access Context

Access Context within a View can be considered a filter of data that goes from C4C to the user. This filter is basically tied to the Work Centre View based on the data that is being pulled to the said view. In a way, the filter forms a characteristic by which the View reports data off. Thus, every view has a predetermined filter and each filter allows the data to be presented to the user based on the user’s authorized access. Another way to put it is that Access Context allows the data to flow through to the user based on what the user is authorized to see and what controls such flow is the Restriction Rules within the Access Context.

Accounts Work Centre View with Access Context 1015 – Employee or Territory or Sales Data

An example would be the Accounts Work Centre View with Access Context 1015 – Employee or Territory or Sales Data. With the mentioned access context, the data presented back to the user in the Accounts View can be controlled via 3 separate ways; i.e. Employee, Territory, and/or Sales Data.

Employee – This allows the data to be filtered based on the user’s assignment into the account team. That means that the user has access to all accounts where he is a member of the account team or if he is the manager of the functional unit where the account is assigned to an employee that sits within the said functional unit.

Territory – This allows the data to be filtered based on the user’s assignment to a Sales Territory where the Accounts are assigned to the said territory. This includes Accounts sitting within the sub-territory of the parent that the user is assigned to.

Sales Data – This allows the data to be filtered based on the Sales Are the user is eligible for. The eligibility of Sales Area is defined in the user’s Employee Master Profile.


Putting it all together

Access Restrictions can certainly be quite complex based on the authorization requirements imposed on the C4C tenant. Much like the authorization in SAP ECC, it is best to approach the subject of Business Roles by creating a matrix of access based on the relevant users and their job functions. Unlike SAP ECC, most of the authorization issues in C4C would involve determining what a Sales Person or Service Desk Person can see. Therefore, it is important to lay the foundation that will facilitate the ease of building Business Roles and the first thing to do is always to understand the Organization Chart of the client; particularly the Sales Organization. Then map out the necessary segregations of the data into the hierarchy within the organization and how each segregation works for a particular user. This is further enhanced with any UI Switches and Fields & Actions that can be defined for a role.

At the end of the day, Access Management in C4C is both an art and a science. Careful consideration of how best to create business roles must be made by giving a thought to balance out the number of roles to be created in the tenant and also the number of users that require authorizations. Hypothetically, we can create one business role per job description but that would only make sense if it fits the requirements based on the hierarchy in the Organization. But in the real world, it is more of a single job description might have different roles catering to different Sales Units in the Sales Organization. Therefore, finding the balance needs both a deep understanding of access contexts and also client expectation management.

1 Comment