SAP SuccessFactors

SAP SuccessFactors is SAP's cloud human experience management (HXM) suite. You can use SAP SuccessFactors as a data source when landing or replicating data.

SAP SuccessFactors integration replicates data using the SuccessFactors HXM Suite OData V2 API with HTTP Basic authentication.

Preparing for authentication

To access your data, you need to authenticate the connection with your account credentials.

To find your API server URL:

Note that the hostname depends on which SAP data center hosts your instance — it is not the same as the URL you use to sign in.

1. Log into your SAP SuccessFactors account.
2. Click your profile picture and select Show version information.
3. Note the Data Center and Company ID values shown.
4. Look up the API server for that data center in SAP's list of API servers. For example, data center DC4 uses https://api4.successfactors.com.

To create and permission an API user:

1. Log into your SAP SuccessFactors account as an administrator.
2. Navigate to Admin Center > Manage Permission Roles and either create a new role for the integration user or edit an existing one.
3. Under Manage Integration Tools, grant Allow Admin to Access OData API through Basic Authentication. Without this the connector cannot authenticate at all.
4. Grant read access to the entities you intend to replicate. Permissions are per module — grant only what you need. Common choices include Employee Central API, Employee Export, and Admin access to MDF OData API.
5. Navigate to Admin Center > Manage Permission Groups, add the integration user to a group, and assign the role from the previous step to that group.

Creating the connection

For more information, see Connecting to SaaS applications.

1. Fill in the required connection properties.

2. Provide a name for the connection in Connection name.

3. Select Open connection metadata to define metadata for the connection when it has been created.

4. Click Create.

Tables replicated

This connector uses dynamic discovery. It does not ship a fixed schema, and there is no fixed list of tables. Discovery runs in two phases:

1. The connector reads your tenant's OData metadata document at /odata/v2/$metadata and creates one candidate table for every entity set the tenant exposes.
2. It then sends a single-record test query to each candidate entity set and drops any that return an error. This removes entities belonging to modules you have not licensed or provisioned, entities the integration user cannot read, and a small number of SAP entities that cannot be queried directly.

The result is that the tables you see are specific to your instance: your licensed modules, your configuration, your custom fields and your integration user's permissions all shape the catalog. Two customers will not see the same list, and a fully provisioned instance can expose several hundred tables.

Table names are the SAP entity set name converted to snake case. PerPerson becomes per_person, EmpJob becomes emp_job. Where the SAP entity name already contains an underscore the result carries a double underscore, so Background_Awards becomes background__awards.

Columns are discovered per table from the same metadata document, so customer-configured custom fields on a standard entity are picked up automatically on the next discovery.

Primary keys are taken from the entity's key definition in SAP's metadata. They are frequently composite, and more than half of all tables have a key spanning two or more columns. Where a key column is inherited from a parent entity, SAP names it <ParentEntity>_<keyName>, for example AutoDelegateConfig_delegator.

Replication strategy is decided per table:

• If the table has a lastModifiedDateTime, lastModifiedOn or lastModifiedDate column, and SAP reports that column as filterable, the table replicates incrementally using the first such column found as the replication key.
• If it does not, the table replicates as full table.

Most tables replicate incrementally, and most of those use lastModifiedDateTime as the replication key. A smaller set, mainly the background__* employee profile tables, use lastModifiedDate.

Parent/child stream relationships

Some SAP entities cannot be queried on their own and are only reachable through a parent entity. The connector detects these relationships from the associations declared in your tenant's metadata and replicates the child table by iterating the parent and filtering on the parent's key. A substantial minority of the tables in a typical instance are child tables.

Each child record carries an injected column named __parent_<parent_table>_<parent_key_column> holding the parent value it was fetched under.

If you select a child table, select its parent table as well. A replication task that includes a child without its parent is rejected when the task is prepared.

Limitations and considerations

• Deletes are not captured. The connector replicates inserts and updates only. A record deleted in SAP SuccessFactors remains in the destination. Use a periodic full reload if you need deletes reflected.
• The catalog is instance-specific. Tables belonging to modules you have not licensed, or that your integration user cannot read, do not appear. If an expected table is missing, check the module provisioning and the RBP permissions on the integration user rather than assuming the connector does not support it.
• Discovery is slow on large instances. The connector sends one test query per candidate entity set, twenty at a time. On an instance exposing several hundred entity sets the first discovery takes on the order of a minute, and the connection form can appear to hang while it runs.
• Effective-dated tables return only currently effective records. Employee Central entities such as emp_job and emp_compensation are effective-dated. The connector does not pass SAP's fromDate, toDate or asOfDate parameters, so these tables return the records effective as of the time of the sync rather than full history. Incremental results on these tables should not be treated as a complete change history.
• Incremental runs can re-deliver boundary records. Each incremental run filters on <replication key> ge <last bookmark>, so records whose timestamp exactly equals the previous run's high-water mark are replicated again. Records are keyed on the table's primary key, so this resolves to an upsert in the destination rather than a duplicate.
• Start Date applies to the initial sync only. Once a table has a stored bookmark, later syncs resume from it. Changing Start Date does not retroactively re-replicate data, and it has no effect on full-table tables.
• Records are read using SAP's server-side pagination. The connector follows the __next link SAP returns on each page until there are no more pages, at a server-controlled page size of 1000 records. This is not configurable from the connection form.
• Rate limits are handled automatically. SAP applies per-instance API limits and returns HTTP 429 Too Many Requests when they are exceeded. The connector honors the Retry-After header, falling back to 60 seconds when the header is absent, across a maximum of 5 attempts. Connection errors, timeouts and 5xx responses are retried separately with exponential backoff, also across a maximum of 5 attempts. The per-request timeout is 300 seconds.
• Password expiry ends replication. SuccessFactors password policies apply to the integration user. When the password expires or is reset, all tasks on the connection fail until the new password is saved to the connection. Configure the integration user so its password does not expire, if your policy allows it.