The ongoing evolution of Technology and its impact on HR.
In the modern age of Digital Transformation, organizations face a herculean task – migrating from legacy systems to best-in-class cloud-based HR systems like Workday. A striking issue that surfaces consistently is the maintenance and organization of User/Worker IDs that were generated throughout the years from various systems. This contributes to a chaotic and convoluted experience when managing and maintaining these relationships. The weeks go by, and several Zoom meetings you weren’t invited to adjourn. Now you’re tasked with the mess of a Data Cleanup Initiative with no idea how to organize and maintain these relationships in your Workday environment. Where do we go from here…?
The addition and integration of new systems and entity relationships call for a concise and meaningful way to map these distributed data entities. Let’s jump right in.
In Workday, we will leverage the “Universal ID” feature to generate a unique User/Worker ID. This ID will also be assigned to all Pre-Hires, Employees, and Contingent Workers on User Creation.
We will review some of the Pros and Cons of the “Universal ID”, and if it is in fact the “One ID to rule them all”.
There are two common IDs in Workday:
- Employee ID/Contingent Worker ID/Worker ID
- Workday ID (WID)
Employee ID, Contingent Worker ID, Worker ID
Some organizations configure a unique ID generator for Employees (EEs) and Contingent Workers (CWs). The resulting behavior is that an EE will be assigned an ID of EE0012345, and a CW will be assigned an ID of CW0012345. This allows a quick visual assessment of a User/Worker on a report or an integration log to determine if they are an EE or CW.
This approach has its pros, but a major con is that your organization will be maintaining two unique sequence generators for all downstream systems, and there is not a true universal sequentially unique identifier for your Worker population.
Another negative surface when you are converting CWs to EEs. In this model, the User’s ID will be reassigned when converting a CW to EE (e.g. A CW with ID CW0012345, will be reassigned to EE0012346). This will most likely cause undesirable behaviors to downstream systems and your IT team will require manual intervention for system administration. However, this can be overcome by setting the SAME sequence generator for ALL Workers (EEs and CWs). A Worker ID strategy that uses the same Sequence Generator would produce an ID of “WO012345”. This uniform model removes the ability to distinguish EEs from CWs by looking at their Worker ID, but it smoothens the CW to EE conversion by persisting the same unique Worker ID across the stages of a Worker lifecycle.
Finally, the biggest Pro for this strategy is that the Employee ID is designed to be passed through the various Integration Connectors that Workday has. If your organization is using Workday for HCM and another platform for Payroll, then passing the Employee ID as the matching key could enable you to use the Workday Delivered Connectors and potentially save time and cost on building a complex custom integration. Consult with your Workday Integrations specialist or reach out to one from EVOCS to confirm which integrations allow for overriding the Employee ID field and which do not.
Workday ID (WID)
Some organizations utilize the Worker’s WID as the unique ID to be propagated into downstream systems. The WID is a Globally Unique Identifier (GUID) that Workday generates and assigns to a Worker’s record in Workday.
The biggest Pro to WID being your organization’s universal User ID is that it is generated automatically by Workday. It is immutable in Workday’s UI or via a Web Service (EIB, etc.). This is a huge positive as no one can “accidentally” modify someone’s WID. A con of the WID is the lack of customizability in its sequence generation. The WID will ALWAYS be a 32-character GUID assigned by Workday.
Secondly, the WID does NOT stay “the same” when converting a Pre-Hire to an EE, Pre-Hire to a CW, EE to a CW, etc. Without a meaningful way to manage this behavior, this inconsistency will cause issues for downstream systems. In the case of User Provisioning in Active Directory (AD), the same user’s WID does not stay consistent throughout the Worker lifecycle.
Lastly, consider the possibility of downstream systems with character limitations of say… 20 characters, or some other number that is less than 32. This varying character limitation between integrated systems is almost guaranteed to be a major pain for all teams involved. Consider the case where leadership (with in-depth knowledge of 3 Zoom calls) decides on a new system that is going to bring in all the ROI’s and cost-savings, but now the HR and IT team is unable to integrate the two systems seamlessly due to character length challenges. Now, you might be forced to create and maintain an “Other ID” to execute on the integration development. This cycle could continue for years, and you are now back to square one with multiple User IDs floating around in spaghetti architecture.
The case for a Universal ID (One ID to rule them all)
Workday released the Universal ID functionality a few years ago, it has gained considerable traction as of late, but is not receiving as much visibility as it deserves. Hear me out!
- The Universal ID can be set up such that it is automatically assigned to all workers at the point of creation in Workday in a sequential and unique manner.
- The security of who can update Universal IDs in Workday can be isolated and locked down to a small group of users (e.g., Security Admin).
- There is a way to assign a sequence generator to the creation of Universal ID’s so Workday maintains it for you, just like the Employee ID.
- The Universal ID persists and stays the same when converting workers from Pre-Hire to EE/CW or from EE to CW.
- There is a way to mass update and/or assign Universal IDs via a Web Service (e.g., EIB).
- The Universal ID can be used as a matching key between Workday and downstream systems (e.g., AD, AAD, Okta, etc.)
- You can restrict who can view Universal IDs in Workday – allowing your organization to lock that down to just the worker-as-self and the Security Admin. This enables the Universal ID to be secure, making it an attractive unique identifier for your workforce that can even be used as the Login ID for your non-SAML applications.
- There is a way to keep your Employee ID and Universal ID generation in sync with each other such that someone’s Employee ID will always equal to their Universal ID. This use case does not apply to all organizations, yet some will find tremendous value.
- The main limitation of the Universal ID is that it cannot be passed as an “override” of the Employee ID attribute in certain integrations.
This post only scratches the surface of outing some of the value you can benefit from implementing a Universal ID for your organization. If you believe your organization would stand to benefit from building a HR-driven Identity Management model, if you’d like to learn more, and especially if you’d like to discuss this approach, please reach out to our Principal Workday Architects at [email protected]. Expect a response within 48 hours.