We are trying to aggregate Custom Attributes from Workday SaaS. The standard attributes and Custom IDs are working, however we cannot seem to pull in data from the Custom Attributes in the Integration Field Override Data.
We set the Integration System ID in Aggregation Settings:
No matter what I do, it seems to remain blank in SailPoint:
Things I have tried:
I tried aggregating WITHOUT anything set in the XPath Schema Mapping for this BirthdayMMDD__c attribute as some suggested here. No Success.
I tried aggregating WITH the XPath added based on the Postman response and based on suggestions others made in previous posts. No Success. wd:Worker_Data/wd:Integration_Field_Override_Data[wd:Field_Reference/wd:ID[@wd:type='Integration_Document_Field_Name']='BirthdayMMDD__c']/wd:Value
I figured out the issue on my own, but want to add the solution here in case anyone finds it useful.
In Workday, the Custom Attribute was named: “BirthdayMMDD__c”. If that is the name in Workday, the name in SailPoint should actually be “BirthdayMMDD__c__c”. Once I changed it to that, it worked.
So the real solution is to name the attribute simply: “BirthdayMMDD” in Workday, then add the schema attribute in SailPoint as “BirthdayMMDD__c”. Important Note: Do NOT add an XPath Schema Mapping entry for these custom attributes. No XPath is needed if you configure it as I outlined above.
I know this may seem obvious to some, but hopefully it clarifies things for someone else in the future.
The __c should only be added in the SailPoint schema, not in the Integration Field Override by WD. You may be able to prove this by using BirthdayMMDD__c__c in SailPoint schema (but may not, tbh).
And, btw, if you wanted to format the date of the birthday (assuming that’s why they did the override) you could have done that with a date transform (still can, if you want to do away with the Integration).
I think we will. After using Postman to see the response, I was able to pull the Preferred Name attributes directly from the Preferred_Name_Data section.
I was also thinking of this. Since we have logic based off of the Birthday in the MMDD format, the idea was this would decrease the complexity of our SailPoint-side logic, since much of that is based on data at the account-level data, rather than the Identity-level.
I do already have a customizer in place for this connector, so formatting it in the customizer might also be an option to reduce the complexity on the Workday side.
HI Seth, maybe not a customizer, I was thinking of a transform on the Identity Profile. ie it’s aggregated as a Date of Birth, then using the OOB Date Format Transform so the Identity attribute contains the Birthday. Actually, thinking about it, storing the DoB on the Identity and then formatting to a Birthday on the outgoing target system connector would actually be my preferred option and more flexible.
