Workday-OnPrem AD- Azure AD Integration issue

Question

Workday-OnPrem AD- Azure AD Integration issue

Here is our setup, ill describe the issue later in the post.

We onboard the employee in workday and an employee id is generated with E000XXXXXX. This employee id is manually copied and entered into a manually new created onprem AD account. This AD account then syncs via Azure AD connect and creates a new account in Azure AD with the same employee id. An internal employee is created with firstnamelastname@abc.com and an external employee is created with email firstnamelastname@extern.abc.com.

Problem statement- The employee id is generated once and is unique. When the external (........@extern.abc.com) is converted to internal (....@abc.com). This actually requires to re-hire the employee on the workday again and eventually generates a new employee id for the user account. If this newly generated emp id is entered in the existing (... @extern.abc.com) onprem ad account manually, this syncs to the azure AD and from Azure writes back to workday. But workday doesnt understand this update , as stated above the emp id is unique for each user account. So basically the only way around is to delete the onprem AD account and create a new account. But you can imagine how painful it is to backup all the data from old account and move to new account. And what if employee has a data of more than 7 years old. I am sure ours is not the first organisation to have this issue. So reaching out to Microsoft to understand what is the best practice and how can we overcome this situation. We dont want to delete the onprem AD account. Rather find a solution where changing the emp id in workday flows flawlessly via onprem AD to Azure AD and changes the UPN/Email of the affected user without any problem.

Thanks

Abi

Answer 1

@Abi The Workday integration reference guide describes one common approach to manage conversions - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/workday-integration-reference#support-for-worker-conversions - but it assumes the WorkerID/EmployeeID remains same during conversions. I understand the scenario you describe is different as a new EmployeeID is assigned to the converted worker.

To address this scenario, we've seen some customers leverage a capability that Workday offers called "Universal ID". Unlike Worker ID and WID that change during conversions, the Universal ID stays the same. This article by a Workday integration partner has a good explanation of Universal ID - https://evocs.tech/workday-universal-id-hr-driven-identity-management/ and how it can serve as a better matching key between Workday and on-prem AD.

Here is high level guidance on how you can use Universal ID in your integration.

• Discuss with your Workday admin/team on setting Universal ID for all users in Workday.
• Identify an attribute in AD and Entra ID to store the Universal ID for all users. For e.g. you can use either an available extensionAttribute or the attribute employeeNumber if it's not already used. Use a PowerShell script or automation of your choice to populate Universal ID on AD user profiles and Entra ID.
• Update the permissions in Workday to grant your Workday ISU account the ability to read Universal ID. The security domain "Person Data: Universal ID" grants access to the Universal ID attribute.
• Configure the Workday to AD user provisioning integration to use Workday API version v30+. You'll need to update the URL and XPATH API expressions as documented here - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/workday-attribute-reference#xpath-values-for-workday-web-services-wws-api-v30
• Include Universal ID in the attribute list with XPATH set to wd:Worker/wd:Worker_Data/wd:Universal_ID/text()
• Configure Universal ID as the matching identifier in your Workday to AD provisioning job. This will ensure that even though the employeeID changes, the same user profile in AD is linked to the source Workday profile.
• Once you enable Universal ID, there will be scenarios in case of conversions where for the same Universal ID, the provisioning integration will get two Workday records, of which only one of them represents active current record. To filter out inactive past records, consider using Workday provisioning groups and use it in a scoping filter so inactive past records are excluded from processing.
• Test your integration scenarios in test environment before promoting them to production.