Workday SaaS Custom ID & Custom Attribute Aggregation Problems

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

Hello everyone,

We are trying to configure a Workday SaaS source in our tenant. All of the connector’s default attributes seem to be working properly, however we have not been able to get data for Custom IDs and Custom Attributes. I had followed the documentation exactly, and have read through every forum post I can find relating to this, but cannot get it to work. We also need to be able to update (sync) 2 of the Custom IDs back to Workday.

The Custom IDs we need to aggregate and update are as follows:

  • Badge_ID__CUSTID
  • Google_ID__CUSTID

The Custom Attributes we need to aggregate are as follows:

  • PREFERRED_FIRST_NAME__c
  • PREFERRED_LAST_NAME__c
  • PREFERRED_MIDDLE_NAME__c
  • BirthdayMMDD__c

Our SailPoint Schema includes all 6 attributes above, exactly as they are, with the applicable __CUSTID or __c suffix. We also have the Integration System ID populated in the aggregation settings.

Our SailPoint XPath configuration is as follows (straight from the documentation):

Schema Attribute: Badge_ID__CUSTID
ns1:Worker_Data/ns1:Personal_Data/ns1:Identification_Data/ns1:Custom_ID/ns1:Custom_ID_Data[ns1:ID_Type_Reference/ns1:ID[@ns1:type='Custom_ID_Type_ID']='Badge_ID']/ns1:ID

Schema Attribute: Google_ID__CUSTID
ns1:Worker_Data/ns1:Personal_Data/ns1:Identification_Data/ns1:Custom_ID/ns1:Custom_ID_Data[ns1:ID_Type_Reference/ns1:ID[@ns1:type='Custom_ID_Type_ID']='Google_ID']/ns1:ID

Note: Based on other forums, the __c attributes DO NOT have an XPath set in the configuration. They are ONLY in the attribute schema. When we aggregate user’s that have data in these Workday fields, SailPoint shows the fields as empty on the account.

When I added Badge_ID to the Create Policy and Sync Policy using those XPaths, I got a successful attribute modify event. We confirmed the attribute was successfully changed in Workday, however, SailPoint still shows a blank value in account attributes.

When I added Google_ID to the Create Policy and Sync Policy using those XPaths, we got an error:
["[ConnectorError] Request execution failed. [Fault Code]: SOAP-ENV:Client.validationError, [Fault String]: Validation error occurred. Element \u0027ID\u0027 is missing attribute \u0027type\u0027 (requestId:

Here are my main questions:

  1. Why are neither the Custom IDs or Custom Attributes not showing up during an aggregation?
  2. Why are the XPaths for Custom IDs using the ns1 namespace, and the default attributes are using wd?
  3. Why did attribute sync work for Badge_ID using that XPath, but we still can’t pull the data?
  4. Why did attribute sync work for Badge_ID work but when tried for Google_ID, it failed, even though they are configured identically in both SailPoint and Workday.

Thank you in advance for your help, I have been trying for days to get this to work.

2

Hi @seth_hexum

Firstly Custom Attributes. From what I can tell you are not looking for Custom Attributes, you are looking for standard Attributes. Just map the XPath and don’t put __c as a suffix.

Secondly, the difference between ns1: and wd: namespace is whether or not you are using the SaaS or VA connector. The documentation is not helpful here (it’s a cut and paste fail), but you should be using the same namespace (I assume wd:). The reason provisioning works is the connector parses the XPath to work out the body to send.

Difference between Badge_ID and Google_ID, I suggest looking at the raw response with Postman or equivalent.

3

Hi @j_place , thank you for the clarifying the documentation mistake. That is very frustrating, however what you suggested did indeed work for Badge_ID. (Google_ID still shows the same error, so I am still trying to figure out why that one is behaving differently). Thank you so much for that!

For the Custom Attributes, all 4 of those are part of the Integration Field Override service and are not standard (so I have been told by Workday).

4

Preferred first, middle and last names together with date of birth are definitely standard attributes, see Get_Workers Operation Details. Of course your WD guys could be doing something weird. As with all aggregations best to test using Postman or equivalent (maybe SOAPUI in this case), the wsdl is in the link above. Your Google_ID is probably a mismatch on the Custom ID Type ID value (case sensitivity?)