SAP SF EC -> MS AD Provisioning Service | Old User Data in Concurrent Employment

Question

Dear Community,

we are using the MS Provisioning Service to replicate User Data from SAP SuccessFactors Employee Central (SF EC) to MS Active Directory. The job has been running for more than a year now all fine.

Now we are facing some strange behaviour:
For some users, who have been rehired in SF EC, the data fields of the old employment are pulled and replicated to AD. For others this doesn't happen.

They are all maintained the same in SF EC. Old employment was terminated, new employment (on same personId) is active.
Even stranger: it works perfectly fine on the Test Environment. Configurations of both Test and Prod Provisioning Services are the same.

For example one users old department is provisioned.
Configuration of the department field has the correct array to always pull the latest data (see below)

Maybe you have an idea, what's causing this? Any help is appreciated!

Thanks,
Sebastian

"apiExpressions": [
                {
                  "key": "User",
                  "value": "$.employmentNav.results[-1:].jobInfoNav.results[0].departmentNav.name_localized"
                }

Answer 1

That expression explains the inconsistency.

Right now you’re doing:

employmentNav.results[-1:] → take the last employment in the array (assuming the API always returns them sorted)

jobInfoNav.results[0] → take the first jobInfo for that employment

In rehire / concurrent employment scenarios, jobInfoNav.results is often not consistently ordered (and can differ per user/tenant), so results[0] can end up pointing to an older jobInfo record for some users.

A simple fix is to also take the last jobInfo record instead of the first, e.g.:

"$.employmentNav.results[-1:].jobInfoNav.results[-1:].departmentNav.name_localized"

That usually aligns better with “most recent record”.

Also worth checking: employmentNav.results[-1:] has the same assumption about ordering. If the employments aren’t returned in a reliable order, you can still pick the wrong employment. The fastest way to confirm is to look at the provisioning logs / EC OData payload for an affected user and verify the order of employmentNav.results and jobInfoNav.results (effective dates, active flags, etc.).