Creating and Customizing Business Roles

A business user is an employee, contractor, administrator, or other person who needs access to the SAP S/4HANA Cloud system. They can be assigned one or more business roles. A business role includes one or more business catalogs that grant access to data and/or applications (SAP Fiori or SAP GUI for HTML apps) for the user to complete their job tasks. The user interface a user interacts with in SAP S/4HANA Cloud is the SAP Fiori Launchpad. The way in which apps are organized on the launchpad is defined by the Space(s) assigned to a business role, and the Page(s) assigned to the Space. Every business role must have at least one Space with at least one Page to define how apps display for a user on the launchpad. Spaces and Pages will be discussed in more detail in a future unit.

It's common for employees within an organization to be assigned one or two roles that provide access to the applications necessary for their primary job responsibilities, in addition to the Employee role. The Employee role provides access to several self-service applications including Manage My Timesheet for time recording, Concur Travel Expense for booking business-related travel and submitting expense reports for customers who also have a license to SAP Concur, My Inbox, which collects workflow tasks from different areas in a single app, and several other applications.

Business catalogs can be added/removed from a business role to grant/revoke access to data and/or applications. Alternatively within a business role, restrictions can be defined that limit the scope of what a business user can view/edit (read/write) in an application.

There are also technical users, which are typically not people, but systems being granted some type of access to SAP S/4HANA Cloud to complete a task. For example, a technical user would be created to pull print jobs remotely when setting up the Output Management (1LQ) business process. In addition, a person from SAP accessing the customer's system to provide a service or support would be a technical user. The Maintain Business Users app is only for human users; technical users are grouped together in their own app - Display Technical Users.

In the Starter system, we recommend using the standard business roles because you can easily assign the necessary permission to a user to demonstrate business processes in the system. In the Development system tenants, the standard business roles can also be helpful if you are testing new features. However, in the customer's Production system, the standard business roles should NOT be used. This may seem counter intuitive, but there are two important reasons:

• A standard business role can grant too much permission to apps or data for an employee. The "minimum level access" rule should be followed, where an employee is only given access to what they absolutely need to complete their job tasks.
• There are cost implications for users completing different functions and/or business processes in the system. Full Use Equivalent (FUE) is the method of a customer allocating their employees access to the cloud system, and there are different pricing ratios for Self-Service, Core, Advanced, and Developer users. This is documented in the GROW with SAP S/4HANA Cloud Service Use Description. The ratios are:
  • 1 FUE = 0.50 developer access
  • 1 FUE = 1 advanced user
  • 1 FUE = 5 core users
  • 1 FUE = 30 self-service users

In the Maintain Business Roles and Business Catalogs apps in SAP S/4HANA Cloud, there is a column called Price Category that shows whether a standard business role is considered development support, self-service, core, advanced, and for some specialty capabilities, individual pricing per catalog (AddOn).

This means you need to build entirely custom business roles for the customer's production system by reviewing each business catalog that grants access to data and/or applications and determining whether or not to add it to your custom business role. This can take several weeks to several months, depending on the size of the project.

First, start with the Application Workplace List accelerator from the Activate Methodology task Create Initial Application - Workplace List. This task should start with a customer expert who is responsible for overall role creation and authorization in their current system, then should move to the line of business (LoB)-specific authorization coordinators/data owners. For example, the Chief Financial Officer is typically the data owner in the Finance LoB. Business catalogs are designed in a way they are free of segregation of duties (SoD) conflicts, so you mix and match business catalogs to create the new custom business roles specific to the customer's organization.

Start in the Maintain Business Roles app and select New to create a new business role. Enter text in the Business Role ID and Business Role Description fields that follows the customer's naming structure for roles and is specific to who the role should be assigned to. For example, if the role will be restricted based on a company code and should only be assigned to project managers located in a specific country, include that in the ID and Description fields. You want a customer administrator to look at the role description and intuitively know who it should be assigned to. After entering these details, select Create.

Select the Business Catalogs tab to choose the catalogs that need to be mapped to the business role.

When you create a new business role, the Access Categories default to the following:

• Write, Read, Value Help: No Access
  • Change this to Restricted.
  • The default value (No Access) means the business role has no Write authorizations (display only). You can add specific authorizations (Restricted) or, in cases where you want to grant full access for all restriction types and restriction fields, you can choose Unrestricted ('*'). Switching the write access to Restricted allows you to define which data can be edited by the users assigned to this business role. You can define the authorization values for the desired restriction fields in the Values area. If you don't want to grant access to a restriction field on purpose, you can choose the status Not maintained.Every authorization you define in the Write access category is inherited by the Read and Value Help access categories.
• Read, Value Help: Unrestricted
  • Change this to Restricted.
  • Switching the read access to Restricted allows you to define which data can be seen by the users assigned to this business role. In the Values section, you can define the instance-based restrictions for the desired restriction fields used for Value Help.Every authorization you define in the Read access category is inherited by the Value Help access category.
• Value Help: Unrestricted
  • Evaluate whether or not this should be changed to Restricted.
  • This refers to the "interlocking squares" that show for some fields, like Business Role Group. It allows the user to see all available options that can be selected in the field and should be restricted sometimes. For example, if visibility to personal data or customer data is possible, Value Help should be restricted to hide that information. If the field is greyed-out, it's likely because there are no business catalogs granting access to any applications where the value help would be accessible.

After verifying the selections in the Access Categories section, select Maintain Restrictions to define restrictions for the Write, Read, and Value Help fields.

Navigate to the Business Catalogs app to see which applications and/or data access are granted through the catalog. The tab, Restriction Types shows the available restrictions you can use with the catalog to limit access to applications and/or data. Alternatively, if you've already assigned a business catalog to your role through the Maintain Business Roles app, you can click into the business catalog and navigate to the same information.

On the Maintain Restrictions page, select the Write, Read, Value Help drop-down menu and choose Restricted. This will provide a set of values you can define restrictions for and should be repeated for the other fields (Read, Value Help and Value Help). Even though it can be a long process to define restrictions for every single field, it's the only way to ensure end users truly have the minimum level of access necessary to complete their job tasks. "Unrestricted" should only be used in rare cases, as it can create security issues with providing users too much access.

A restriction marked as a Leading Restriction means the value entered in that field is automatically inherited by other restriction types that also use that field. For example, if you want to ensure the values for the country templates for Austria (AU01) and Switzerland (CH01) are applied in all restriction types for the field Company Code, you would enter the relevant values and select the Leading Restriction checkbox. These values would then be automatically inherited to all occurrences of the Company Code field in the role.

1. Select the "pencil" icon to edit a restriction.
2. In the Field Settings section, select Restricted.
3. In the Values section, you see the available options in the current SAP S/4HANA Cloud system. Select the checkbox to the left of a restriction value. This will automatically save and update on the Values screen to the left within a few seconds.
4. Select the checkbox for Leading Restriction to pass the restriction value on to other relevant restriction types this field happens to be used in too.
5. Repeat steps 1-4 for all restrictions.
6. The business role has been automatically saving this entire time, so you can select the back button in the top left corner to navigate back to the original Maintain Business Roles page and save the role.
7. Always make sure to assign the customized role to a user and test it out to verify the restrictions are accurately hiding/showing what you want them to.

Each time a release upgrade occurs, there will likely be some type of business role maintenance necessary. The Maintain Business Role Changes After Upgrade app displays changes to business catalogs and restriction types after an upgrade. For example if a new restriction type was added to a business catalog, or if an existing restriction type is being phased-out or has been officially removed. It's important to check the Release Assessment and Scope Dependency Tool in the What's New area of the SAP Help Portal to get a big-picture understanding of how the customer's actual business processes are affected after a release, then focus on targeted apps like the Maintain Business Role Changes After Upgrade app for detailed information about how user permissions may be affected.

Learn more about Identity Access Management here:

• SAP Blog: SAP S/4HANA Cloud Public Edition Identity Access Management - Your Knowledge Base
• Learning Journey: Managing User Identity and Access in SAP S/4HANA Cloud Public Edition