Name: Deep Diving into Assignment of Business Roles in SAP Sales Cloud
Uploaded: 2020-10-22
Duration: 545 s
Description: In this video, you'll take a deep dive into the concept and usage of business roles and gain an understanding of applying in various settings.

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>In this video, you'll take a deep dive into the concept and usage of business roles and gain an understanding of applying in various settings.<br></div></div></div></div>

Deep Diving into Assignment of Business Roles in SAP Sales Cloud

Hello, my name is Manny. In this video, you'll take a deep dive into the concept and usage of business roles and gain an understanding of how it can be applied in some settings. I'll begin with the concept of a local and global Atman to understand when to use a local administrator role. Let's look at an example. Imagine a company implements the SAP Sales Cloud solution in a phased approach into their different regions all over the globe. Typically, the rollout activities include related key user activities managed by a team of central key users located in the company's headquarters. An important part of the regional rollout includes training the local admins. Local admins are responsible to act in the role of an immediate contact for local users, and the maintenance of local employees and users. With the concept of the local administrator. It's possible to centrally define roles which can be reused by local administrators and to manage the users for whom they are responsible. These roles are set up to have access rights to create and maintain only the users for whom the local administrator is responsible. Let's see how a local ad man is set up. I first began by looking at the global administrators role. A global administrator locks into the system and creates a role for a local ad man. A global administrator fills in basic data like the name of the business role. And navigates to the scope option, select manual and flags the role as a local role. And the user's responsible pane. I click on the user list icon to display the listing of users and user IDs. I'll click cancel. Clicking the Add Role option assigns a local at man as a responsible user for a global role. This step makes this role also available for the local ad man. Next, I'll restrict the access to the local admin head. This is required for viewing and editing relevant data within the sales organization for whom the role is responsible. I'll select the Access Restrictions tab. Here I can define the Rewrite Access for Work center view by selecting Restricted or Unrestricted. Notice that the access for the two work center views is set to unrestricted. This access can be restricted by use and restriction rules by using a predefined rule. This allows access only for the employees and the local admins. Own sales organization and advantage of user restriction rules. Is that the same local at my role can be reused for different regions of the company. Since the restriction role takes care of regional applications, for my example, I'll change the read and write access to restrict it to save my changes. I'll click save. Next I'll click actions and activate the role. If you are used in territory management roles or distribution roles, you may want to limit the administrators access rights to only maintain relevant roles. This is why the local Atman restriction rule comes in handy. How does it work? If the roles are countries specific, you can limit the local admins to maintain the data for which they are responsible. As a best practice, we recommend to have a direct relationship between one type of business user and a business role. As an example, all sales representatives uses one common business role call sales rep and a customer support employee has this role defined as SAP Sales Cloud provides flexibility and a way that one business user can have multiple business roles assigned if needed. For example, a business user can have a sales rep role and a customer support role assigned at the same time. You may wonder how access restrictions work in such a case. Which role? President. The answer is if a user is assigned to more than one business role, and the business roles have different access restrictions for the same object, then the highest allow access restriction applies to the business user. As an example, if a business user is assigned to the sales rep role, granting unrestricted access to the account object and a customer support role, granny has unrestricted access to the account object. Then the user that has both business roles assigned will enjoy edit privileges on the account. If you need to have different read or write access for the same business object, this would be a case to use two business roles assigned for the same business user with different restrictions applied. Business roles. Sales rep one has read access based on role one. Territories employees for managers write access would need to be different than role one, so we use no access for this business role for business roles. Sales rep two we apply different restrictions since we want the right access as per role for access based on the employee only. We'll choose this option. In our example, the results show the sales rep will be able to see accounts that fall under restriction rule one and for access based on the employee territory assignment and involvement of employees reporting to user and org unit, including SAP unit. However, when it comes to editing, this is more restricted. Basically, access is based for employee only. Next let's look at the concept of US switches. You ask switches are defined with custom development and SAP Cloud Application Studio and can be used to make custom UI like fields, buttons or sections of user interfaces. Hidden rate only or mandatory. An alternative option for UI configuration without using SAP cloud applications Studio is User Page Layout. We'll have a deep dive into this functionality in a later video. In this series. In the chat for UI switches, I'll click on Add Row. Here I can assign any UI switches that have been previously created. This configuration makes the link between the desire UI UI switch and the sales rep business role. Using this example, user seven, the business role is assigned to can view these UI changes. I'll click on the identifier. And select the Sales rep layout from the list and save our changes. Next is the Fields and Actions tab. Here I'll apply restrictions from three perspectives. Business fields, extension fields and restrict access to specific actions. Let's say that within the account object I want to restrict access to the field call encode terms to be read only. I'll click Add Row and select the account object and the corresponding field. Next I'll set the access restriction to read only for extension fields. The steps are the same. I'll click add row and select the business object and the corresponding extension field to restrict. Note that extension fields can be created via key user tools or through SMP cloud applications. Studio can subsequent will be available here for selection. In this example, I'll select the credit info number and make it read only for this business role. For business action restriction, let's see how to disable for the option for creating accounts for sales reps. I'll click on arrow. Next, I'll search from the existing actions for the account customer in the account business context. I'll select the. Make sure that the access is set is disabled. To save my changes, I'll click save.