We’re trying to sync an Identity Attribute with a custom ID that was created in Workday.
This looks to be supported based on: Aggregation and Provisioning of Custom IDs
The XPath of the attribute that we’re trying to sync to is:
We’ve tried this Xpath with a Schema name of: SYSTEM_USERID__c and also SYSTEM_USERID__CUSTID
Using SYSTEM_USERID__c we can get the value from Workday after an aggregation.
With SYSTEM_USERID__CUSTID we cannot.
Both schema names, when trying to sync to Workday - the error received is:
[“openconnector.ConnectorException: [ ConnectorException ] \n [ Error details ] Exception : No custom objects configured in the restCustomObjectAliasMap.”]
Our Workday team say it’s an issue on the SailPoint side. Anyone tried to sync custom attributes/IDs before to Workday via the standard OOTB connector and encountered this?
Hi @adama Ignore the __c suffix, that is for Integration Field Override scenarios, ie Custom Attributes.
The __CUSTID suffix, as I understand it, indicates to ISC to look into the Custom_ID_Data xml blob, ie Custom IDs. I’m not sure why it is required as that xml blob is included when Personal Information is requested, but bear in mind that it has different permission requirements (Person Data: ID Information) for the Workday ISU account that you are using.
One thing to check is the Custom_ID_Type_ID “Reference ID” for the Custom ID type you are querying. Can you confirm the XPath using Postman (or equivalent)?
Hi @adama The reason I ask whether you have validated the XPath using Postman is that your Custom_ID_Type_ID (“System_UserID”) looks very like the descriptor for a Custom ID rather than the Type ID, which would be something like CUSTOM_ID_TYPE-6-10. Check with the WD team if you can’t validate via Postman.
Got it. Thanks for the added information. We have confirmed that we can both get and update the value using the XPath. Current status is that we’ve got a ticket open with SailPoint support and they’re trying to get more information from the relevant connector team, I’ll update this thread when we have more information/and or a working solution.
The solution was on our end - for the custom ID, it was as simple as the XPath attribute name.
So we had SYSTEM_USERID__CUSTID in the Schema Attribute and just SYSTEM_USERID in the XPath Attribute mapping. What we needed was SYSTEM_USERID__CUSTID in both. Which is different to integration fields, which only need __c in the schema mapping, but not in the XPath mapping.
After doing this, we were able to write back the custom ID.
It wasn’t immediately clear to us in the documentation here: Aggregation and Provisioning of Custom IDs However, Sailpoint connector team have taken this onboard and will emphasise the requirement.