25,080 questions
EntraId to SuccessFactors Writeback | Error with userId
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(41.6, 18%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWS%3C/text%3E%3C/svg%3E)
Wieland, Sebastian
20
Reputation points
Dear Community,
we are facing a issue in the Provisioning Writeback Service from EntraID to SAP SuccessFactors.
We configured the service on our Development Environment in Entra and successfully provision email information to the SuccessFactors TEST tenant.
We then moved the configuration to the PRODUCTIVE Entra environment and connected to the SuccessFactors PROD tenant, where we receive the following error message:
Checking the OData Audit Log on SF side, we can see the service is trying to use the SF userId in the $filter. However, the userId like this is truely not filterable. The path should be $filter=userNav/userId, as it is checking the wrong entity.
Strangely in the Development Environment the exact same Service is using SF personIdExternal in the filter - which is working without any issue.
Here's the mapping:
Switching the matching precedence didn't change anything.
We also changed the connections to use the Entra DEV to connect to SF PROD, which worked. And the Entra PROD to SF TEST which gave us the same error.
So the issue has to be within the Entra Prod.
Is there any way to change the behaviour of the Odata Filter call?
Any hint would help!
Thank you,
Sebastian
Microsoft Security | Microsoft Entra | Microsoft Entra ID
{count} votes
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(192, 22%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESD%3C/text%3E%3C/svg%3E)
Sakshi Devkante 4,395 Reputation points Microsoft External Staff Moderator2025-01-31T15:01:20.0666667+00:00 Hello @Wieland, Sebastian
Thank you for posting your query on Microsoft Q&A.
The issue lies within your Entra ID production environment, particularly concerning the OData filter applied during provisioning from SAP SuccessFactors. you can modify the attribute mappings in Entra ID to adjust the OData queries
Navigate to the Entra ID portal.
Go to Enterprise Applications and select your SAP SuccessFactors provisioning app.
Click on the Provisioning tab.
Under Mappings, select Synchronize SuccessFactors Users to Entra ID.
In the Source Object Scope field, define attribute-based filters to control which users in SuccessFactors are in scope for provisioning.
For instance, to filter users based on their status, you can set a filter like userStatus NOT EQUALS 'inactive'
Review the existing attribute mappings to ensure they align with the data structure in SuccessFactors.If necessary, add new attribute mappings or modify existing ones to match the correct OData paths.
After making the necessary changes, save the configuration.Run a test provisioning cycle to ensure that the modifications resolve the issue.
refer to the official Microsoft documentation on configuring SAP SuccessFactors to Entra ID user provisioning:
the SAP community provides insights on bidirectional integration between SAP SuccessFactors and Entra ID, which might offer further assistance: https://community.sap.com/t5/human-capital-management-blogs-by-members/bidirectional-integration-between-sap-successfactors-azure-active-directory/ba-p/13510597?utm_source=chatgpt.com
Recheck the configuration again
PreHire needs to activated in Entra ID provisioning app: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/sap-successfactors-integration-reference#how-pre-hire-processing-works
You also need to sync active employment record in Entra ID provisioning app: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/sap-successfactors-integration-reference#retrieving-current-active-employment-record
And in SAP Successfactors your API user needs some permission, which might be unknown: https://community.sap.com/t5/human-capital-management-q-a/not-getting-data-for-future-hires-in-successfactors-to-azure-ad-integration/qaq-p/12600662 (i guess you'd need a SAP support user to access this). Abstract: In SAP Successfactors - Ensure that the API user account has Manage User > Employee Export permission.
if the issue still persist then you may need to contact both EntraID and SAP SuccessFactors support teams. They can help investigate whether there are any configuration issues or known bugs related to provisioning behavior between environments.
Best regards,
Sakshi Devkante
-
Sakshi Devkante 4,395 Reputation points Microsoft External Staff Moderator
2025-02-03T11:19:59.2033333+00:00 Hello Wieland, Sebastian
I am following up to see if the suggestion provided above was helpful to you. If you have any further questions or need additional assistance, please don’t hesitate to reach out.
Best regards,
Sakshi Devkante
-
Sakshi Devkante 4,395 Reputation points Microsoft External Staff Moderator
2025-02-04T16:08:11.52+00:00 Hello Wieland, Sebastian
I am following up to see if the suggestion provided above was helpful to you. If you have any further questions or need additional assistance, please don’t hesitate to reach out.
Best regards,
Sakshi Devkante -
Wieland, Sebastian 20 Reputation points
2025-02-06T17:14:53.11+00:00 Hello Sakshi,
unfortunately this didn't help with this case.The Advanced Options are showing the userId OData Path to the default $.employmentNav.results[?(@.userNav != null)].userId
The path is correct and points to the "right" userId (in Employment)
However this path is not used in the call to SF for the filter as you can see in the Odata Log of SF.
The further information provided is referring to the Provisioning Service from SF to AD, which is not our scenario here. We are only looking at the Writeback. So PreHire / ReHire are not relevant here.
Permissions in SF have been verified. An issue here is anyway not conclusive, as the call is successfull to SF.
Any other ideas?
Best Regards,
Sebastian -
Wieland, Sebastian 20 Reputation points
2025-02-06T17:16:23.6966667+00:00 But thank you for your support anyway!
Sign in to comment
Sign in to answer