Implementation Design Principle

PUBLIC

SAP SuccessFactors Suite: Design and

Implementation Considerations for Role Based
Permissions
Document Details
Name Objective Audience
Design and SAP SuccessFactors Customers: IT
This IDP will draw upon experiences from
Implementation and HR professionals.
implementations and support situations to
considerations for
Role Based provide guidance and a reference for customers SAP SuccessFactors
who are either in the design stages or looking to
Permissions Implementation Partners:
review their current permissions set up to Consultants, solution architects and
improve upon their initial design. project managers.

Change Log
Version Date Description
1.0 1st March 2020 Initial version
1.1 5th May 2020 Template adjustment and reference updated
1.2 30th July 2020 RBP reporting enhancements released as part of 2H 2020 updated,
language improvements, added quick searches to review
permissions, and other minor enhancements

Supported Releases
Product Release - From Release-Valid
till
SAP SuccessFactors Employee Central 2105

Contribution
Role Name Organization
Author / Owner SAP SuccessFactors Product Management SAP SE
Author Ankita Mistry IBM
Author Nicholas Iodice EY

The recommendations in this document are based on the functionality available up to SAP SuccessFactors
release mentioned above. Future functionality can impact the recommendations provided by this document.
We strive to keep these recommendations up to date, however, in case you find that recent new functionality
has not yet been considered in the latest version of this document, please reach out to your Customer Success
Manager / Partner Delivery Manager or send an email to SAPSuccessFactorsIDPDoc@sap.com.
Implementation Design Principles (IDPs) for SAP SuccessFactors solutions are delivered by SAP for helping
customers and partners on how to choose the most appropriate strategy and solution architecture for SAP
SuccessFactors implementations. IDPs are compiled taking into consideration the experience of many
implementation projects and addressing frequent business requirements as well as real-life implementation
challenges. They are continuously reviewed and updated as product functionality evolves. In addition, the
reader is advised to read and familiarize with essential and additional product-related documentation which
includes Implementation Guides, SAP Notes, SAP Knowledge Base Articles and additional assets as they are
referenced in this document, see chapter 0.

2
TABLE OF CONTENTS
1 TERMINOLOGY ............................................................................................................................................ 4
2 ABSTRACT ................................................................................................................................................... 4
3 INTRODUCTION ........................................................................................................................................... 4
4 BUSINESS REQUIREMENTS ........................................................................................................................... 4
4.1 COMPLIANCE WITH DATA PRIVACY REGULATIONS .............................................................................................................. 4
4.2 MAINTAIN SYSTEM PERFORMANCE ................................................................................................................................. 4
4.3 EASE OF MAINTENANCE ................................................................................................................................................ 5
5 SOLUTION OVERVIEW AND CONCEPTS.......................................................................................................... 5
6 DETAILED SOLUTION .................................................................................................................................... 5
6.1 ENGAGE RBP CONSULTANT AND RBP BUSINESS OWNER DURING EC DESIGN ........................................................................ 6
6.2 PERMISSION ROLE DESIGN............................................................................................................................................ 6
6.3 PERMISSION GROUP DESIGN......................................................................................................................................... 8
6.4 MAINTAIN A SINGLE CONSOLIDATED RBP WORKBOOK FOR LARGER IMPLEMENTATIONS............................................................ 8
6.5 LIMIT NUMBER OF USERS WITH ACCESS TO MANAGE RBPS.................................................................................................. 8
6.6 SEPARATE ACCESS SHOULD BE SET UP FOR SPECIFIC ADMIN ROLES WHERE OVERLAP MAY BE REQUIRED ........................................ 9
6.7 SET UP A GOVERNANCE PROCESS .................................................................................................................................... 9
6.8 SET UP PERIODIC RBP REPORTS ..................................................................................................................................... 9
6.9 RBP CHANGE AUDIT REPORTS .................................................................................................................................... 11
6.10 NAMING CONVENTION.......................................................................................................................................... 12
6.11 OTHER PERMISSION CONSIDERATIONS...................................................................................................................... 13
6.12 CHECK TOOL ........................................................................................................................................................ 14
7 REFERENCES ...............................................................................................................................................17

3
1 TERMINOLOGY

Abbreviation Description

EC Employee Central

MDF Meta Data Framework

RBP Role Based Permissions

UI User Interface

2 ABSTRACT
For larger global organizations, considerable thought and effort needs to be invested in designing Role Based
Permissions. Governance, Maintenance and Performance aspects need to be also considered upfront during
the design stages. This IDP will draw upon experiences from implementations and support situations to provide
guidance and a reference for customers who are either in the design stages or looking to review their current
permissions set up to improve upon their initial design.

3 INTRODUCTION

Without a good understanding of key concepts and an adequate RBP design, customers will encounter
numerous challenges which should be avoided at all costs. Such issues may come in the form of legal fines
due to misappropriation of sensitive data, degradation of system performance due to inefficient configuration,
or possibly even increased operating costs due to complexity of design maintenance. To avoid these
challenges, customers should develop strong security models during the onset of their implementation in
accordance to the design principles below, as a poor RBP design can become increasingly difficult to roll back
and untangle.

4 BUSINESS REQUIREMENTS
The following sections will introduce the Security and System Design Requirements.

4.1 Compliance with data privacy regulations

RBP design should address all data privacy requirements that apply to a customer.
As part of any SAP SuccessFactors implementation, safeguarding workforce data is of paramount priority.
With an increasing number of countries adopting strict legislation, such as General Data Protection Regulation
(GDPR), appropriately managing sensitive information has become both a moral and legal obligation. As stated
earlier, misappropriation of employee data may result in costly legal fees. As a rule of thumb, abide by the
principle of least privilege – grant as minimum required access, to as few users, for as short of a span,
as possible.

4.2 Maintain system performance

Customers working with complex security requirements across different businesses and countries lead to
employees having multiple redundant roles. This adversely affects the system performance.
System performance impacts the length of time it takes to generate reports, process jobs, load pages, and so
forth; therefore, customers will want to ensure SAP SuccessFactors is performing at an optimal level to
maximize benefits and facilitate a seamless user experience. Two primary aspects of an RBP design will

4
influence system performance – total number of permission groups and overlapping permissions granted by
multiple roles; ideally, both should be minimized as much as possible. Target fewer than 1,000 total permission
groups and ensure users are not receiving the same permission(s) from more than one role.

4.3 Ease of maintenance

When working with a large number of permission roles and permission groups it is important to have a clear
understanding of what changes need to be made in order to address a new security requirement. The RBP
design should be easy to understand and hence easy to maintain.
Organizations are dynamic which means their RBP setup needs to be as well. The easier an RBP design is to
understand and maintain, the lower its corresponding operating costs will be. It is extremely important to have
a clear understanding of the design’s interdependencies. When managing many permission roles and
permission groups, properly addressing new security requirements becomes complicated.

5 SOLUTION OVERVIEW AND CONCEPTS

SAP SuccessFactors leverages a role-based permission framework, to manage system security. Often
referred to as “RBPs,” role-based permissions consist of two components: permission roles and permission
groups. Permission roles are comprised of various privileges to system data and functionality. Permission
groups are populations of users that have been grouped together who share specific attributes. Permission
groups can either be static – defined by specific usernames or dynamic – based on user attributes. These
groups are further segmented into ‘owner’ and ‘target’ populations. Owner populations (also known as granted
group) include users that are assigned permission roles, which grant specific privileges they can perform for
or on their associated target population(s). Additionally, relationships (hierarchical or non-hierarchical) may be
leveraged to assign permissions. The total number of permission roles and permission groups should be kept
as low as possible, as too many will be difficult to manage and hinder system performance; however, the
system does not define configurable limits.

Based on customer use cases and an understanding on the RBP infrastructure we have put together a set of
guidelines that can be used as a framework when designing the RBP for large customers with complex security
requirements.

6 DETAILED SOLUTION

This chapter provides generic design guidelines and concrete examples addressing the previously outlined
business requirements. Due to the complexity of the topic and the specifics of each customer, the outlined
advice must be tailored to the concrete customer situation at hand.

5
6.1 Engage RBP Consultant and RBP Business Owner during EC design

It is beneficial to engage your RBP consultant and business owner(s) when designing the Org Structure and
Employee Classification components like Business Unit, Division, Department, Employee Class, Employment
type and Process Design to have insight into available data attributes for RBP design. For example: If there is
a new field being defined to distinguish between Hourly and Salaried employees, it might be useful for the RBP
consultant to understand this criteria or if there is a special security requirement for a special group of people,
the RBP consultant and EC consultant will be able to find a more efficient way to group that desired population.
It also helps the RBP consultant understand the process needs, that drive the security requirement.

6.2 Permission Role Design

To understand which permission roles are required, refer to your HR operational model which defines the
various HR roles within an organization as well as their corresponding responsibilities and activities. The details
encompassed in process maps will allow you to identify which activities are performed and by which parties.
The collective activities performed within SAP SuccessFactors by each party will define your permission roles.
For example, imagine your process maps include a swim-lane for HRBP. Every process step within this swim-
lane outlines an activity conducted by HRBPs. To configure your HRBP permission role, consolidate the steps
involving SAP SuccessFactors and translate them into specific RBP permissions. This will ensure any
individual responsible for HRBP activities will have a permission role available that accounts for all access
required to perform any steps defined within the process model. Further, you now have a backbone to your
RBP model – permission roles are defined by the process model – meaning, any adjustments to permission
roles should be accompanied by a corresponding modification to the process model and vice-versa. Data
privacy and protection should be incorporated in the design by default, access should be based on what is
minimally required to execute allotted HR responsibilities. Strive to develop a global role framework, as
localized requirements will necessitate multiple variations of the same permission role.
For example, when developing an ESS role (Employee Self Service), start with employee access that is
consistent globally. If a country requires a deviation from this global ESS role, either the global ESS role would
need to be changed (which would change access for all employees globally) or a net new localized ESS role
would need to be configured and granted in addition to the global ESS role. Below screenshot shows the
schematic representation of the approach.

Every employee will get the Global ESS Role plus the Country ESS role that the employee belongs to. Below
is the representation of role assignment for Country A employees.

6
This approach makes it easier to carry out changes that are global whether it is addition of a specific permission
or removal, at the same time still making it possible to make local changes within the Country ESS roles.
Careful considerations have to be made before finalizing on a design approach based not only just upon the
size and spread of the customer but also keeping in mind the ongoing maintenance efforts post go live, that
are in line with the security/governance model practiced by the customer. Some of the pros and cons of the
above design are listed below:

Pros Cons
Global changes can be made easily by updating just one Changes to the global role will affect the entire employee
single role population
Local country specific changes can be easily made by Good understanding of the current security design and
updating the country specific role stringent governance model required to decide which role
the changes are to be made in
Fewer roles to maintain as opposed to having to maintain During a phased go-live by country, advance planning by
a single role for each country all countries needed in deciding what goes into the global
role
Consider creating a Login Role which enables granted population to login to the application. This will come in
handy during phased implementations, go-lives, system lock down situations etc.,

7
6.3 Permission Group Design
To understand which permission groups are required, refer to your HR delivery model. Whether supported by
offshore service centers and/or local HR teams, these variations will determine which permission groups are
needed. While designing, strive to minimize the total number of permission groups. Defining populations at a
more granular level will increase the total number of permission groups needed. If multiple levels of target
populations are required, consider if configuring at the more granular level only will allow you to reduce the
total number of groups. For example, imagine both country and region-based permission groups are required;
perhaps country-based permission groups could be stacked to form regions, rather than configuring both
country and region-based permission groups. Below graphic shows usage of country specific groups to arrive
at North America Region, eliminating the need for a separate region group.

To achieve a strategy for recycling permission groups among the various modules; design with a long-term
mindset, while also solving for immediate project goals. An Employee Central go-live may be the near-term
focus; however, additional modules may be on the future road map and could influence permission group
requirements. Strive for dynamic group derivation rather than static, while utilizing data attributes that are
stable and consistent across the RBP model. Consider which permissions may be managed via user
relationships and apply a logical, clear naming schema.
Guidelines:
• If a group is to be defined and modified using individual usernames, then it is recommended to create a
static group for the purpose instead of dynamic group, as it is better from a performance standpoint.
• Reuse existing groups wherever possible and avoid creation of duplicate groups. Include a step to check
existing groups before creating new groups. A good naming convention and understanding of security setup
is crucial to have an efficient RBP setup. Refer to section Naming Convention for further details.
• Employee data should be loaded first before creating RBP groups.

6.4 Maintain a single consolidated RBP workbook for larger implementations

The workbooks for RBP for Talent modules v/s Employee Central may be disparate since fields may be
added/removed from the Employee Central workbook and the corresponding permissions need to be added
accordingly. However, in case of large implementations, it is advised to maintain a single consolidated RBP
workbook which is updated whenever there is an addition/update of fields in Employee Central. This is
important to ensure visibility of the roles that overlap between Talent permissions and Employee Central
permissions

6.5 Limit number of users with access to manage RBPs

In terms of ongoing security management, a very small team should be responsible for the on-going
maintenance of RBPs. RBP Super Administrators are users with permission to “Manage Role-Based
Permission Access,” which enables the ability to grant access to manage permission groups and roles. To
mitigate the risk of unintended changes in system security and/or foul play, strive to keep the total number of
users with these permissions as low as possible. These individuals can grant any access within the instance;
and therefore, should be designated very cautiously. Develop strong audit control processes to ensure
changes are kept under check.

8
6.6 Separate access should be set up for specific admin roles where overlap may be required
Through this IDP we talk about not providing overlapping permissions to users. From a business as usual
perspective, admin roles may be an exception to that. They may need overlapping access since they need
visibility into the data irrespective of other employee roles that they are part of. Hence it is advised to maintain
separate roles for different types of admins. This will ensure a small number of people have the required
access. Sample roles include:
• SFAPI / Integration admin
• Reporting roles
• Module-specific admin (EC, LMS, PM/GM, Comp)
• Master Data Admin

6.7 Set up a governance process

Set up a process specific to SAP SuccessFactors with the required approval chain for any access that needs
to be provided. Ensure this governance process at least includes an approval from the RBP Design/Security
owner. For example, identify who can make updates to RBP configuration? Who’s approval is needed before
changing configuration? When should a new permission role or group be created? The process should ensure
existing roles and groups are checked for reusability before creating new ones by having approvals built into
the process and justification provided before creation of new roles/groups. The governance process should
also ensure the RBP workbook is updated every time that changes are made to RBP configuration. The
process should be able to track all change requests, record the reason for change and ensure change
approvals.

6.8 Set up periodic RBP Reports

Periodic RBP review should be done using available SAP SuccessFactors tools like RBP Ad Hoc reports and
Change Audit Reports. RBP roles should also be checked for changes from time to time to ensure there is an
audit of the request due to which the permission role/group was updated.
Below are reports types available that can be generated and compared periodically

1. RBP Permission Roles Report

This report identifies the permission roles defined in your system along with the Granted and Target population.
This report provides a good high-level picture of the RBP set up in the system, especially in environments
where one role has multiple granted and target population rules.

2. RBP User to Role Report

This report can be used to identify the Permission roles assigned to each user. You can periodically compare
this report to check who was assigned a new role.

3. RBP Permission to User Report

9
The report can be used to identify the specific permissions assigned to each user. This report can also be used
to audit specific permissions for each role by removing the User related columns. Ideally two separate reports
should be created 1. For non-MDF related permissions and 2. For MDF related permissions.

4. RBP User to Group Report

This report can be used to identify users within a permission group. This report can be used to compare the
movement of employees in and out of groups.

As of release 2H 2020, the RBP user to group report has been enhanced to include inactive employees as
well. The security admin can run the report on a periodic basis to identify recently terminated employees and
(if needed) could remove them from the permission groups that they belong to. This will ensure the employee
doesn’t automatically get permissions upon rehire that he/she is not supposed to have.
The enhanced report also supports Assignment ID as a field available to extract in the output if it has been
enabled in the data model. For more details on Assignment ID refer to the KBA 2825052 – Assignment ID.

5. Dynamic Group Definition Report

Apart from the above RBP Ad-hoc reports, Dynamic Group Definition Report provides the Include and Exclude
People Pool criteria that is used to define the dynamic permission groups. Additionally, other fields such as
dynamic group name, total member count and last modified date are available. This report can be enabled
through the integration center. Refer to the RBP Implementation Guide section ‘Dynamic Group Definition
Reports’ to get further details on how to enable and setup the report. It is recommended to run this report
frequently for audit and compliance purposes.

10
In addition to RBP Ad Hoc reports, you can also use SAP SuccessFactors Odata APIs to develop your own
custom queries for audit purposes

• To Get the list of all Dynamic Groups

https://<hostname>/odata/v2/DynamicGroup
• To Get the exact Dynamic Group
https://<hostname>/odata/v2/DynamicGroup(4980L)
• To Get the Include and the exclude criteria
https://<hostname>/odata/v2/getExpandedDynamicGroupById?groupId=4980L&$format=json
• Get all Roles by User ID
https://<hostname>/odata/v2/getUserRolesByUserId?userId='sfadmin'
• Get the specific role
https://<hostname>/odata/v2/RBPRole(602L)
• Get all the rules of the Role - you get the list for Rules (Rules are the granted, target group pairs for the
particular role and some more information)
https://<hostname>/odata/v2/RBPRole(602L)?$format=json&$expand=rules
• Get the Target Group or groups
https://<hostname>/odata/v2/RBPRule(741L)/targetGroups
• From the target group get all the users as part of the group.
https://<hostname>/odata/v2/getUsersByDynamicGroup?groupId=4643L

6.9 RBP Change Audit Reports

The change audit functionality within SAP SuccessFactors enables to audit/track changes to personal data,
system configuration, or other business data including changes to RBP. It is important to note, the audit reports
cover a maximum period of seven days and requirements needing a longer period of time should be catered
to using multiple reports. Refer to the implementation guide Change Audit.
The following RBP change audit report types are available:

1. RBP Role Change Report

This report is used to audit changes done to RBP permission roles.

11
2. RBP Group Change Report
This report is used to audit changes to RBP permission groups. It is important to note that the RBP Group
change report only provides change information about dynamic groups. Currently group change report doesn’t
provide details about changes to static groups.

3. RBP User Role Change Report

This report is used to audit changes made to RBP role assignments.

4. RBP Static Group Membership Change Report

As of release 2H 2020, a new type of change audit report, RBP Static Group Membership Change Report is
available. This report can be used to track changes made to the members of RBP static groups such as who
was added or removed from a static group and when did the change occur.

6.10 Naming Convention

For clearly articulating the corresponding usage of each permission role and group, it is important to develop
a standardized naming schema. By reading the name of a permission role, one should be able to comprehend
the capabilities and purpose of said role. If the name alone is still not specific enough, it is recommended to
add a description, this facilitates later maintenance.

12
Similarly, the name of each permission group should indicate exactly how and for whom it is leveraged. The
following format may be used as a baseline:
[Population]_[Permission Role]_[Granted/Target]
By inputting example values into this format, it becomes clear that a “UnitedStates_SuperAdmin_Granted”
permission group would be leveraged to define the population of Super Admins within the United States.
Ensure to be consistent with labeling. For example, permission groups and roles that inconsistently reference
“United States,” “US,” “USA,” “United States of America,” and/or “America,” will be more challenging to search
and manage. Consistent usage of labels will allow security admins to easily search terms and find all their
corresponding permission groups and roles.

6.11 Other Permission considerations

Some other considerations that may help reduce the complexity of RBP design are as follows:

o Data Access Period Settings: Restrict access to data based on time period.
SAP SuccessFactors provides a data blocking function that controls exactly how long individual roles
will be able to access historical personal data, based on their role-based permissions. For example,
if HR Admins require to store address information for 3 years whereas Payroll Admins might have to
store it for 5 years. In such a situation the data access period settings can be used to give access to
HR Admins and Payroll Admins for visibility of data for different time periods.
It is important to note data blocking is only available in Employee Central and Reporting.

o Associations:
The visibility of objects like Event Reasons and Pay Components can be controlled using association.
Using association to control data visibility for Pay Components instead of defining different
permissions for it.

o Business rules with workflows:

13
 Using a combination of business rule and workflows to mitigate situations which require very specific
permissions. For example: Trigger a different workflow, if the transaction is initiated by an Admin v/s
HRBP, in order to mitigate additional access.

o Reports:
Reports are another mechanism that can be used to prevent creating new roles. For example: If Ad
Hoc reports do not follow field level permissions; the user can receive a report instead of having to
see the data on the UI
o Quick Searches:
Use the quick searches: User Role Search and View User Permission when you need to quickly
consult the permissions of an employee.

o Workflow design:
Another decision point will come as part of workflow design, for which you will decide whether RBPs
should be respected. By default, this functionality is set to “No,” which allows workflow participants
to see all fields applicable to Workflow Approval screens, regardless of their typical RBP constraints.
Conversely, this functionality can be set to “Yes,” which restricts the fields workflow participants will
see based on RBP configuration. Workflows not respecting RBPs should not impact your RBP
design; however, for those that do, you will want to consider which fields various workflow participants
should/will have access to during the workflow approval process. When evaluating various decision
points such as these, consider the level at which you need to design your security model to enforce
‘good-behavior’ rather than trusting your HR professionals to act accordingly.

o Relationships:
Leverage user relationships such as HR Manager, Comp Manager, Matrix Manager, Global
assignment manager, to assign role-based permissions instead of creating special groups/roles for
these requirements.

o Extend by n days
Using ‘Extend by N days’ a user can receive earlier access to employee data by setting the system
to show data earlier, for example, 30 days before the transfer. Usage of this feature may remove
the need to create additional temporary permission roles for managers, HRBPs, etc., who may be
involved in a transfer, hire or promotion.

6.12 Check tool

The check tool runs diagnostic tests on your RBP configuration and provides a solution if any issues are found.
This tool is especially useful for large implementations where there is a higher possibility on reaching the upper
limit on the ideal number of permissions roles, rules and groups.
Below are instructions on how to use one of the diagnostics tests provided. For additional details, please refer
to the SAP Note 2321200 - BizX Platform - Troubleshooting RBP issues: Admin tools & reports [Including
Check Tool].

1. Go to the Check Tool and select the Application as Role-Based Permissions

14
2. Expand the rows to see all the checks available for your instance

3. Select the check you would like to perform and click Run Check (one or more checks can be run at a time)

15
4. Once the checks are completed, relevant messages are generated for each check that identified an issue

Click on the error which you would like to analyze. For example: 1 issue is reported for the check “Verify if
number of rules associated with a role exceeds 100”. Click on that issue to see the analysis and resolution
provided by the Check Tool.

5. As per the reported issue, the permission role ‘HR_Tier2_Reporting’, has 130 rules associate with the
permission role i.e., there are 130 granted and target population combinations.

6. Check this role in the system and as per the ‘Proposed Solution’ analyze if there are any rules that can be
eliminated to keep the number of rules low. Once you consolidate the number of rules and update the
permission role, rerun the check tool and ensure the number of rules have reduced below 100.

16
7 REFERENCES
SAP Notes/KBAs
• 2321200 – BizX Platform - Troubleshooting RBP issues: Admin tools & reports [Including Check Tool]
• 2766870 – Role Based Permissions (RBP) Refresh Framework FAQ - SuccessFactors
• 2798822 – Accessing Future Transfers and Hire
• 2825052 – Assignment ID

SAP Documentation

• SAP Implementation Guide – Implementing Role Based Permission

• SAP Implementation Guide – Using Role-Based Permission
• SAP Implementation Guide – Using the Check Tool
• SAP Implementation Guide – Change Audit
• SAP Implementation Guide – Managing Employment in Employee Central

Architectural Leading Practices (ALP)

• Permission Framework

17
 Implementation Design Principle

www.sap.com/contactsap

© 2020 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.