Skip to Content

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).

blog_auth_assign_br.PNG

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:
blog_auth_adapt.PNG

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./wp-content/uploads/2014/12/blog_auth_clr_616563.png

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.

/wp-content/uploads/2014/12/blog_auth_work_together_616601.png

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!

Further reading

The SAP Cloud for Customer Administrator Guide (http://help.sap.com/saphelp_sapcloudforcustomer/en/PDF/EN-2.pdf) provides a lot of detailed information. The link should remain working after a new release, the page numbers are correct for version 1411 of the document.

  • Business Roles: page 189 and further
  • Page Layouts: page 375 and further
  • Code List Restrictions: page 378 and further
To report this post you need to login first.

16 Comments

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

  1. Anand Thakur

    Great Article Joost!!

    Is it also possible to restrict result set by data..e.g If i do a query then i see all sales transactions under my region, whereas if my colleague does it he sees only the ones which he manages.

    kind of like authorization object concept in the tradition erp world?

    Regards

    Anand

    (0) 
    1. Joost Janssens Post author

      Hi Anand,

      Thanks. Your requirement can be solved via Access Restrictions in the business role: per object, you can there indicate the read and write access. For example, you can set up territories to indicate which sales rep works on which customers. Then, in the business role setup, you can create, as an example:

      • business role for the sales rep, limiting the appointments by their own territory, and
      • another business role for the sales manager, limiting the appointments by the employees assigned to the employee

      Best is to take a look at the business role screens: some objects have slightly different access restriction options.

      br

      Joost

      (0) 
  2. Matthias Braeuer

    Hi Joost

    Excellent collection of tips and best practices. I second the advice to switch off the personalisation option for regular users.

    There are still some interesting quirks in the solution with regards to the application of layouts across the different user interfaces. For instance, we found that the Email field on the account overview page could only be made read-only via the master layout in the HTML5 UI. However, this change would not flow through to Silverlight and the classical (native) iPad app.

    Also, when creating page layouts for different screens of the same business object based on instance types and business roles, one has to be careful that this can lead to problems with adjusting screens that are not specific to an instance type but should be made specific to a business role (*phew*).

    For instance, assume we have defined:

    1. two business roles: Sales Rep and Sales Manager;
    2. two page layouts for the account business object: Prospect and Customer. The layouts show different screen elements on the account details page based on whether the account is a prospect or a customer.

    We then assign the Prospect page layout to both Sales Rep and Sales Manager business roles for all accounts with BP role Prospect. We do the same for the Customer page layout.

    Instance Type
    Prospect Customer
    Business Role Sales Rep Prospect Layout Customer Layout
    Sales Manager Prospect Layout Customer Layout

    With a setup like this, it seems to be not possible any more to have a different layout configuration for the account overview list based on the business role (say, remove one column for the sales rep) because the instance type does not apply there. It appears that this view defaults to whatever is defined in the master layout in this case. However, it’s also not possible to create an entirely new sales rep-specific page layout for the account overview list and remove the instance type when assigning it. Since it is the same business object, removing the instance type would remove the ability to have different overview screen layouts for prospects and accounts.

    In SAP CRM on premise, the assignment of layouts was a bit more flexible as the search key for the layout always considered the UI view first, and sub-types of the business object second. Maybe there is a way in C4C as well to realise this requirement.

    Cheers Matt

    (0) 
  3. Ciro Bastos Zanata

    Hi! I need do hide some itens on “Reason of Rejection” from Sales Quote but can’t find Quote in Business Object dropdown list in Code List Restrictions Screen.

    Have any idea?

    Thanks!

    (0) 
    1. Natalia Goyenechea

      Hi Ciro,

      Reasons for rejection can be added/deleted from the fine tuning.

      Go to business configuration, activity list, Fine tune, and search for the activity “Reasons for rejection” (make sure you show all activities and not only the the ones in project)

      add the activity to project if necessary, and add or delete  reasons in that activity.

      I hope this helped!

      Natalia

      (0) 
      1. Ciro Bastos Zanata

        Hi Natalia! thanks for your help, I create my reasons for rejections via fine-tune but, in my case, i need to hide two reasons items for specific business role, and display for others roles.

        It’s possible?

        []s

        (0) 
  4. A. de Lange

    Hi all, I have added a page layout to a business role which makes it possible to authorize sales managers using C4C to only edit accounts with role ‘Prospect’. Once the checkbox ‘Prospect’ is unchecked, the account becomes a ‘Customer’ and is sent to SAP ECC. It should not be possible for sales managers using C4C to edit accounts with role ‘Customer’. Customers may only be edited from ECC. The assignment of the page layout to the business role works perfectly, but is not refelcted in the Mobile C4C app (both Android and Iphone). This still makes it possible for anyone with the C4C app and access to the Accounts workcenter to edit customers. Does anyone know a solution for this problem? Kinds regards, Anne

    (0) 
    1. Benjamin BONNET

      Hello Marc,

      It is not possible ton only gray out “Edit Master Layout” but as only administors have access to the Adapt menu you have a way to restrict access to that feature.

      Best regards,

      Benjamin

      (0) 
  5. Sathish Ganesan

    Hi Joost,

    Excellent tips. I have a question though. I was able to add extension fields to 3 available but unused tabs screens on ticket and use them in page layouts. However, when I created a new tab screen and tried to create an extension field the tab screen does not show up for creating extension fields but only the ticket header region is available.

    -Sathish

    (0) 
  6. Julia Bayrhammer

    Hello,

    link in document (help.sap.com/saphelp_sapcloudforcustomer/en/PDF/EN-2.pdf) is not working anymore.

    Is it possible to export users and authorization from a tenant and import it into another tenant? I’m asking because of “tenant copies” from prod tenant to a test tenant. In this case a new tenant is created with users and roles from prod tenant. Is there an easy way to maintain users and roles after this “copy”?

    Regards,
    Julia

    (0) 
  7. Nicholas Moth

    Hello,

    I wonder if anyone would be able to help with our issue. We have placed Access Restrictions on the Work Center Views for Ticket and Queue so that an Agent cannot read and write the Tickets from other Org Units.

    However an agent is still able to use the Search tool in the left pane in order to search for a Ticket assigned to a different Org Unit. They can then read and write to these Tickets by accessing them through the search.

    Does anyone know if there is a way that we can restrict the Search in the same way we have restricted the Work Center View?

    Many Thanks,

    Nick

    (0) 

Leave a Reply