Authorizations in SAP Cloud for Customer: business...

joost_janssens3 · ‎12-30-2014

Hello,

In this blog I would like to share what I learned about authorizations in SAP Cloud for Customer. To start with the key takeaway: authorizing users can be done by more than just doing some settings in a business role. There are a few mechanisms available in SAP Cloud for Customer that work together in building up the screen and allowing or disallowing certain functionalities. I will go through them one by one, just high-level, and then wrap up with a summary. Please note that the blog is reflecting my views and ideas. It's always a good idea to also check SAP's official documentation. Links are provided at the end.

Business Roles

When talking about authorizations in SAP Cloud for Customer, business roles should come to mind first. Every user needs at least one business role to be able to see Work Centers (e.g., Customers) and Views (e.g., Account). For each of the views, Access Restrictions can be setup to limit which data is available. Moreover, with Business Actions you can control certain actions. This way, you can for instance disallow certain business roles to create an account.

Did you know: you can assign multiple business roles to one user. At runtime, the system will a) show all Work Centers and Views that have been assigned in at least one of the assigned roles, and b) apply access restrictions and business roles that are set in any of the business roles.

So? In a big implementation or with complex requirements, this allows you to create big generic business roles, that only deal with assigning work centers and views, and smaller ones that merely deal with the access restrictions or business actions.

Where to find it? Check out Work Centers Administrator or Application & User Management. A business role is assigned to a business user by opening the Business User and then via the Assign Access Rights option (see screenshot below).

Page Layouts

OK, so we know which Work Centers and Views our user may see. Often, there might however be more specific requirements that should be met. If you do not want to allow certain groups to see particular data, like sensitive pricing information, you can use Page Layouts. Next to the Master Layout, which will apply to all users, you can create a specific Page Layout for a business object and assign it to a Business Role and an Instance Type. Instance Types differ per business object, but you can basically think of dropdown fields on the object header. Examples are ABC Classification on the account and ticket type on the, yes.. ticket.

With Page Layouts, you can create specific layouts for each combination. Fields can be hidden, set to read-only, or made mandatory. You can also create new fields (but that goes beyond the focus of this blog). Facets (tabs) on objects can be shown or hidden, and new ones can be created. You can also remove some buttons (e..g, the Add button on an object work list).

This makes it a very powerful tool, but be sure not to exaggerate: it should still be manageable! Also, take into account some of the...

Golden Rules of Page Layouts

Consider the following when working with page layouts:

Per object, you can select the Instance Type you use for assigning page layouts. This is the 'active' instance type and the only one that is considered. You can change it, but then the old instance type is no longer taken into account.
Every list field you create via Key User Tools is also available as an Instance Type for assigning Page Layouts.
With a page layout, you cannot add fields which are not on the master layout. You can hide master layout fields, or make them read-only.
If you add a field to the master layout after you created page layouts, the field will also be added to all the existing page layouts. Be sure to hide the fields on a page layout again, if that is necessary.
You can export and import individual page layouts, as well as the master layout. This allows you to move page layouts to another tenant if you have a multi-tenant landscape. For instance during a UAT, it ensures your business users have tested the same stuff as they will see in Production.
If more than one page layout is found (e.g., because the user has multiple business roles):
- visibility: the field is invisible, if at least one page layout sets it to “hidden” (“AND logic” - all have to set it to visible)
- read-only and mandatory: the field is read-only/mandatory, if at least one page layout sets it to read-only / mandatory (“OR logic”)
Note: If you plan to use a large amount of page layouts, consider using empty business roles purely for assigning page layouts. This is easier than having to assign a page layout to all the relevant business roles each time. You can assign both the 'real' and the empty business roles to a user.

Where to find it? In HTML5, an administrator will be able to see the Adapt option in the top right:

When you logon in Silverlight, you will find a great report called Layout Change History in the Administrator Work Center. It is a bit technical, but it offers a complete overview of what has been done to what layout. I think it is a good basis for your documentation, in case you need to write it.

What about Personalization?

Next to page layouts, the system offers an elaborate Personalization option. Although consultants probably love playing around with it, my strong advise is: switch it off. It will lead to a unpredictable end user experience and when questions arise, no one will know how the screen exactly looks. Instead, talk with your business users and ensure that the screens fit to their needs.

Where to find it? You can switch User Personalization off (or back on) in the Company Settings (in the Adapt menu in the top right). It is available in both HTML5 and Silverlight.

Code List Restrictions

Now that we know which fields are shown for which users, we can use Code List Restrictions to limit the list of possible values in a dropdown. These Code List Restrictions can be set up generically of per business role. There is an option to create a dependent list by selecting a control field. This works similarly to the Instance Type in Page Layouts and can be both a standard or extension field.

Where to find it? In Silverlight, you will find the Code List Restrictions option in the Administrator Work Center.

Working together

When you combine Business Roles, Page Layouts, and Code List Restrctions, you have a great way to influence what a user can and cannot do in SAP Cloud for Customer.The following picture shows how these work together.

Related options

Next to the three standard functionalities of Business Roles, Page Layouts, and Code List Restrictions, you can also create logic via the Partner Development Infrastructure(PDI), for example to show or hide fields based on certain criteria.

Also worth looking into is Workflow. With this functionality, you can, during save, update a field in an object based on a condition. Now if you make a specific Page Layout on the field you change with a workflow rule, you can dynamically alter the screen layout dependent on what the user fills out and saves.

As this blog focuses on auhtorization options available in standard SAP Cloud for Customer, PDI and workflow are not further explored here. It is good to know that they exist.

Summary

As said in the introduction, my key takeaway is: authorizations in SAP Cloud for Customer is more than just about business roles. If you remove a button via Page Layouts or hide an option via a Code List Restriction, the user is also not able to execute certain functionalities. Coming from SAP CRM on Premise, these concepts are slightly different from PFCG and webUI, but in the end the same can be achieved. It just requires a different way of thinking and some getting used to. If these functionalities do not fulfill your requirements, PDI or workflow probably will. However, in many cases, Business Roles, Page Layouts, and Code List Restrictions will do the trick. And don't forget: it's a cloud product with multiple releases a year! If it is not possible now, it might be in the future. Another reason to stick to standard!

Before I wrap up, some words of advise:

Gather all the requirements, also for future extensions (new roll-outs, new user groups, etcetera) before you start to setup the final set of business roles, page layouts, and code list restrictions.
When things look complex, they typically are. Make everyone aware that these tools are highly flexible but, as a consequence, can be very hard to support. Especially page layouts deserve some consideration: do you want generic page layouts for a country or role, or a combination, or do you want more specific ones (maybe per business object or even on instance type level)?
Think about naming conventions. As the system usage grows, so does the amount of business roles and page layouts. If you have a smart naming convention, it will save a lot of searching. I cannot give an advise on the naming though: it -again- depends on what your business wants to achieve.

Thanks!

...for reading this blog. Have fun with SAP Cloud for Customer!