Deploying SuccessFactors Business Rules Trigger (BRT)

Overview 

SuccessFactors Business Rule Trigger (BRT) - an automation tool that monitors data changes in SAP SuccessFactors and automatically triggers existing business rules to keep related data objects aligned, hosted on SAP Business Technology Platform (BTP).

BRT integrates with your SAP SuccessFactors environment via the OData API user (technical user). It is hosted on the Ingentis SAP BTP tenant in Amazon Web Services (AWS) data centres in Sydney, Australia.

Environments in Scope

All tasks in this guide must be completed in both environments:

• Test / UAT environment
• Production environment

Solution Architecture Overview

SuccessFactors Business Rule Trigger (BRT) is a Java-based application deployed on the Ingentis SAP Business Technology Platform (BTP) tenancy, hosted in the Amazon Web Services (AWS) data centre in Sydney, Australia. It communicates with your SAP SuccessFactors instance over HTTPS using OAuth2 SAML Bearer Assertion.

BRT Architecture

BRT runs on Kyma runtime within the Ingentis BTP provider account. The solution is logically divided into three components:

• Provider Account (Kyma Runtime): Hosts the BRT application, shared across all Ingentis tenants.
• Extension Account (per customer instance): One extension account is created per registered SuccessFactors instance. The SAP SuccessFactors Extensibility service establishes an OData destination. The XSUAA service handles Single Sign-On (SSO) via SAML2.
• Database Account (SAP HANA Cloud): Each tenant has a dedicated JDBC connection with a separate database schema and credentials, stored as Kubernetes secrets.

Integration & Authentication Flow

BRT follows this integration pattern:

• Users authenticate via SAP SuccessFactors (SSO via SAML2 / XSUAA). No separate login is required for BRT.
• User roles are resolved from SuccessFactors to determine application permissions. The shell role must be created in SuccessFactors.

• BRT communicates with SuccessFactors via the OData API over HTTPS, authenticated via OAuth2 SAML Bearer Assertion using the Technical User credentials.
• Sessions have a 30-minute idle timeout and a 12-hour maximum duration. Role changes require the user to log out and back in.

Data Security & Encryption

Data security is managed at the SAP BTP platform level:

• Data at Rest: SAP HANA Cloud native encryption (AES-256). Data volume and redo log encryption are applied by default.
• Data in Transit: All communication between BRT and SuccessFactors is over HTTPS. Database connections are secured via TLS 1.2 and encrypted with the TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256 cipher suite.
• Platform Security: SAP BTP data centres hold ISO 27001, SOC 1, SOC 2, C5, CSA STAR and ISO 22301 certifications.
• Configuration logs are retained for the duration of the contract.
• Firewall: SAP is responsible for implementing and monitoring firewall rules on BTP. The only customer action required is IP whitelisting for OData API access, if enforced. BRT does not store sensitive HR data - it works only with object IDs and date values.

Information Required from you

Before Navigo can generate an integration, token or begin the deployment process, the following information must be provided for each SAP SuccessFactors instance.

Required Item	Details
SuccessFactors Company ID	The Company ID for the Test and Production instances respectively.
Landscape URL	The login URL for each SuccessFactors instance (e.g. https://[tenant].successfactors.com).
Extension Center Status	Confirm whether Extension Center (SAP BTP integration) is enabled in each instance.
Technical User ID (BRT)	The User ID (not login name) of the technical user created for BRT in each instance.
IP Whitelisting Status (optional)	As an added layer of security, you may block the technical user to have restricted access. Org.manager IP address described in the following section

 

Users, Roles & Data fields

The following data fields, users and roles must be configured in SAP SuccessFactors prior to deployment. These users and data fields must be set up in both the Test and Production environments.

The naming convention for roles and users is flexible; the names provided below are indicative only.

Data fields

As a dependency on the BRT being implemented, new fields need to be added to SuccessFactors in both Test and Production environments for the purpose of BRT to monitor for updates, and to target the changes. These new fields are-

• Cust_DateTimeNAVIGO
• Cust_StampNAVIGO

These new fields need to be created for each object that BRT is intended to monitor and update.

BRT relies on specific data attributes to support its triggering mechanism. Each source data type requires a custom DateTime attribute that is populated with the current timestamp whenever relevant changes occur, driven by a business rule. Each target data type requires a custom String attribute that is updated with the same timestamp to enable saving of the related object. The BRT listens for changes in the DateTime attribute on the source object and writes the timestamp to the corresponding String field in the linked object.

Technical User

The technical user is a local SAP user created specifically for API access. It does not require login access to the SuccessFactors admin panel. A separate technical user is required for each environment - two in total:

• BRT Technical User – Test environment
• BRT Technical User – Production environment

Technical User - Required Permissions

A technical user is required to access the OData API to read and write data. Therefore, no login to the SFSF admin panel is required. The technical user needs read and write access to all objects and fields that will be monitored and written to by BRT. The following permissions are required so that BRT can run correctly:

Permission Category	Required Permission(s)
Manage System Properties	Picklist Management and Picklists Mappings Set Up (This permission is required to show possible picklist values)
Metadata Framework	Access to non-secured objects (This permission is required to show possible picklist values) Admin access to MDF OData API (This permission is required to make use of the snapshot pagination parameter. Without that parameter, invalid data may be caught from SFSF on large data sets)

In addition, the technical user requires read and write access to all objects and fields that are configured as part of the BRT evaluation paths. The specific objects depend on your configured scenarios - Navigo will confirm the exact field-level permissions required during the deployment engagement.

The below table includes an example of the objects and fields that the technical user is given permissions to:

Data Object	Data Elements
Department	externalCode
Department	Cust_DateTimeNAVIGO
Department	Cust_StampNAVIGO
Department	ParentDepartment
Job Classification	Code
Job Classification	New DateTime field
Job Classification	New custom string field
Position	Code
Position	Cust_DateTimeNAVIGO
Position	Cust_StampNAVIGO
Position	DepartmentCode
Position	changeReason
Position	technicalParameters
Business Unit	Code
Business Unit	New DateTime field
Business Unit	New custom string field
Division	Code
Division	New DateTime field
Division	New custom string field
EmpJob	UserId
EmpJob	New DateTime field
EmpJob	New custom string field

IP Whitelisting 

If your organisation enforces OData API access control via IP whitelisting in SuccessFactors, the following IP addresses must be whitelisted to allow BRT to communicate with SuccessFactors.

Test Environment	Production Environment
52.62.41.199	52.65.20.196
54.153.202.148	52.64.42.76
13.236.220.23	13.211.63.17

If your organisation does not enforce IP-based API restrictions, no action is required for this section. However, it is recommended that the BRT technical user is restricted to just these IP addresses for an added layer of protection.

Deployment Process

The deployment process must be completed for both environments (Test and Production). The steps below are sequential - Navigo cannot commence configuration until all pre-conditions are confirmed.

Step 1 – Provide System Details

Provide Navigo with the SuccessFactors Company ID and Landscape URL for both environments. 

• Responsible: Your ICT / SAP Applications team
• Output: Confirmed Company ID and Landscape URL for each environment

Step 2 – Navigo Issues Integration Token

Upon receipt of confirmed system details, Navigo generates and provides an integration token for each environment. Each token is valid for 7 days from the date of issue.

• Responsible: Navigo
• Output: Integration tokens for Test and Production environments

Step 3 – Activate Integration Token in Extension Center

For each SuccessFactors instance (Test and Production), complete the following steps:

1. Log in to SAP SuccessFactors as an administrator.
2. Navigate to Admin Center → Extension Center.
3. Select the Extensions on SAP BTP tab.
4. Under Add Integration with SAP BTP, enter the integration token provided by Navigo and click Add.
5. Wait until the linked sub-account displays a status of Integrated.

Step 4 – Create Technical Users

Create the BRT technical users in SuccessFactors as described in the previous section. Two users are required - one for Test and one for Production. Assign the correct Permission Role.

Once created, provide Navigo with the User ID (not login name) for each technical user, specifying which environment each belongs to.

• Responsible: Your ICT / SAP Applications team

Step 5 – Configure Support User Access

Assign the BRT shell role to the Navigo support user accounts in all environments. This enables the Navigo team to access and verify the BRT application from the outset.

Step 6 – Create Shell Role and Assign to Support user

Create the Navigo_Businessruletrigger shell role (or your preferred name) in SuccessFactors. Assign this role to the nominated test users in all environments.

• Responsible: Your ICT / SAP Applications team

Step 7 – Navigo Commences Deployment

Once all steps above are confirmed complete and the readiness checklist has been returned to Navigo, the Navigo team will commence technical deployment and configuration of Business Rule Trigger.