We are seeing inconsistence in Employee type value for users using workday saas connector.
For all the active users employee type reference id value is fetching into sailpoint where as for all the inactive users(Terminated / Future hire) employee type business object name is getting fetched into sailpoint. Can anyone help me in understanding why there is difference and also let me know if any configuration changes is required?
For example: Temp Staff is Business object name and Temp_staff is Reference Id name.
Active users value is coming as Temp_staff
Terminated/Future Hire value is coming as Temp staff
The inconsistency in “Employee Type” values, where active users show a “Reference ID” (e.g., Temp_staff) and inactive users (terminated/future hire) show a “Business Object Name” (e.g., Temp Staff), is a common Workday integration challenge. This discrepancy likely arises from how Workday’s APIs present data for different worker statuses, with the SaaS connector then ingesting these varying formats. Workday might expose the structured “Reference ID” more readily for current, active records, while for historical or future-dated records, it might default to the more descriptive “Business Object Name” in its API responses.
To achieve consistency in SailPoint ISC, the primary solution involves using Transformations applied to the Workday source. First, you’ll need to understand what Workday is actually sending. This often requires working with your Workday administrator to inspect the raw API responses or using SailPoint’s Source Debugging feature to capture the raw data ingested by the connector. Once you confirm the incoming format, you can then configure a Before Provisioning Transformation (or a Before Creation Transformation if it’s for new accounts, though aggregation transformations are more common for this scenario) on the employeeType attribute. This transformation would identify the “Business Object Name” format (e.g., by checking for spaces) and convert it to the desired “Reference ID” format (e.g., Temp Staff to Temp_staff), ensuring all users have a standardized employeeType value in ISC.
I’m going to guess that this is because ISC processes transaction (event) data for pre-hires and terminated workers, rather than static data. AFAIK, it has to do that (or use Effective Dates) as the Worker Type attribute doesn’t exist for a pre-hire or terminated worker as it’s associated with the Position, which the Worker doesn’t have in these scenarios.
I would suggest 2 workarounds:
Use the Business Object Name for all by updating the XPath Schema Mapping for EMPLOYEE_TYPE to reference the Descriptor of the Reference ID, eg.
Bear in mind, the descriptor may not be as immutable as the Reference ID.
Create new ISC Employee Types: “Pre_Hire” and “Terminated” and assign via Transforms based on other attributes, ie if Start Date in future then Employee Type=Pre_Hire
I appreciate neither of these may match your particular requirements, but number 2. is my preferred solution as it is “more true”, ie these Workers don’t actually have a Workday Worker Type at this point in time.
PS - I believe the VA based connector is more functional in the area of Reference ID to Descriptor mapping by employing ReferenceIDMaps, so that is option 3.