SuccessFactors: Move to Workload Identity

Replacing a stored password in an HR integration is worthwhile, but the change must preserve the feed that creates and updates employee identities. Authentication success and correct provisioning are different results.

Microsoft’s 12 October Entra roundup includes generally available workload identity support for SuccessFactors provisioning.

It is a change to plan jointly with the people who administer Entra, SAP Cloud Identity Services and SuccessFactors.

Draw the trust relationship before changing it

Microsoft’s configuration guide describes Entra issuing a short-lived OIDC token, SAP Cloud Identity Services validating it, and a further token being used against SuccessFactors. The SuccessFactors client remains mapped to a technical/API user with role-based permissions.

Removing a long-lived credential does not automatically reduce that user’s permissions. Review those permissions independently. They should match the entities and operations the provisioning integration needs, with a named owner who can explain additions.

Create a configuration record containing the tenant and application identifiers, the intended SuccessFactors API host and the administrators responsible for each side. Keep secrets and bearer tokens out of ordinary change tickets. Identifiers and sanitised failure details should be enough for the initial investigation.

Have both teams compare the trust values directly with the documented configuration. A similar application name is weak evidence when a test and production system coexist.

Keep data mapping out of the authentication change

Freeze unrelated attribute and matching-rule edits while testing the credential transition. Otherwise, a new permission, changed source value and modified matching rule can all produce the same visible symptom: an employee account that looks wrong.

The SuccessFactors integration reference explains how the configured matching attribute links a source record to an existing target account. An unmatched record can lead to creation. That is why the validation set should record the expected target object, not only the employee’s current display name.

Select approved test records covering a new starter, an existing employee with a harmless attribute change and a leaver in the non-production system. If the organisation uses writeback, include a separate authorised writeback case. Do not use a real termination event to test a connection change.

For each record, capture the source identifier, expected target identifier, expected changed attributes and values that must remain unchanged. This keeps the test specific enough to identify a mapping failure without exporting the entire HR dataset.

Prove each stage, then observe a normal cycle

Microsoft’s guide provides a connection test for the token exchange and API call. Follow it before activation, then validate provisioning itself. A connection test can establish access to an endpoint while missing a permission needed for a less common entity or workflow.

Use four separate acceptance checks:

1. The new authentication method reaches the intended SuccessFactors instance.
2. A known source record matches the expected directory object.
3. A controlled change arrives correctly through the configured provisioning path.
4. A subsequent ordinary cycle completes without unexplained failures or duplicate work.

Record which checks ran in the test environment and which ran after production activation. A successful laboratory run is evidence for the proposed configuration, not a claim that production has already passed.

Assign someone to inspect the next scheduled or incremental processing cycle. The change owner should not close the task immediately after saving the new authentication setting. Agree what evidence the HR team will review and when they should report a discrepancy.

Investigate the failing stage

Separate trust validation, API authorisation and provisioning logic in the support runbook. An issuer or audience mismatch belongs with the trust configuration. API access denied belongs with the mapped client and its permissions. Wrong attribute values require review of source data and mappings.

Microsoft documents relevant SAP identity-service and OData audit logs in the same configuration guide. Preserve a sanitised correlation record that lets the two teams compare the same event. Do not copy full employee payloads or authentication headers into a broadly visible ticket.

Keep a deliberate recovery path. The guide permits returning to basic authentication only while SAP still supports it; that is a conditional fallback, not a permanent migration strategy. Confirm the currently supported route before the change and retain only the credentials needed for the agreed recovery period.

After stable processing has been accepted, remove the superseded stored credential through the approved process and update ownership records. The existing OAuth application consent review is a useful companion for checking application access, but the HR feed still needs its own operational owner.

The completed change should leave evidence of both improvements: the old authentication dependency is removed, and the expected identity lifecycle continues to work.

References

• Microsoft — October Entra announcement, 12 October 2026. Accessed 17 October 2026.
• Microsoft — Configure workload identity for SAP SuccessFactors provisioning. Accessed 17 October 2026.
• Microsoft — SAP SuccessFactors integration reference. Accessed 17 October 2026.