Year: 2025

There is not a set time for companies to award compensation, but I’ll go out on a limb and say that most Workday customers conduct annual compensation reviews at the end of the calendar year. People expect compensation around the holidays and the New Year. And in my fifth year of leading Workday Advanced Compensation projects, I still see the same mistakes. Admittedly, I have been guilty of these mistakes. Sharing my perspective as an Advanced Compensation consultant who has completed over 10 implementations and 20 projects, my goal is to help you avoid some of them. About half of my experience is in client advocacy or post-production support, and that means I see the post-implementation struggles.  Let’s start with People. Choosing your team and consultants for implementation of Advanced Compensation (merit, bonus, stock) is the most important step towards a successful implementation. Thinking about choosing the right firm or partner; make sure you agree upon exactly which person(s) will be assigned to your contract before the work is started. It is important that the lead consultant on your project understands Compensation and its role in business, that they have implemented the module at least three times prior, and that they have led at least a couple of their projects. Everyone starts somewhere but I do not want to own the project where learning happens. As Workday continues to experience tremendous growth, we will continue to see fast hiring, training, promotions, and title inflation in the Workday job market, so the experience and talent depth on some Workday consulting teams is diluted. Right up there next to People is your Timeline. Plan to complete your implementation at least a month before your Compensation Review Process is initiated in Workday. Projects often run behind schedule and trust me that there will be enough stress about finalizing employee participation and budget in the final weeks. A good consultant can use Workday to help you calculate budget through Workday reports and tools such as the Bonus Accrual Estimator.  In your contract, specify that hypercare support begins approximately a week before the day of launch and ends shortly after compensation review has been finalized or compensation statements released (if applicable). Hypercare during a gap between the migration to Production and initiation of your compensation process is during downtime and useless to you as a client. You will need some support in making final changes, corrections, loading the budget, and launching the compensation review process which is why I recommend that hypercare begin about a week before you launch. Finally, it is with a heavy heart that I recommend you avoid BIRT (Business Intelligence and Reporting Tool) to create your Compensation Statements. It is hard for me to say this because I am a BIRT consultant and enjoy using the tool. Use BIRT for compensation statements and you are going to have a bad time. If you already have an internal team that knows and understands reporting and BIRT, this recommendation is not for you. For most Workday customers, BIRT is too costly and complicated. BIRT is a tool in Workday Studio that allows technical report developers to create pdf layouts that print when you run a report in Workday. It is commonly used to develop offer letters, paychecks, compensation statements, and other business documents. BIRT is not a tool that a report writer can learn on their own without some mishaps. Regarding compensation statements, problems often arise for these reasons: Testing: Compensation is complicated, and many different versions of the compensation statement are needed. If a condition rule or calc field is written incorrectly, it affects many statements. Testing compensation statements is very time consuming, and testing needs to happen before every compensation review cycle. To fully test, the pdfs need to be reviewed and not just the report that populates the data into your statement. If my client is small enough and has the staff, I will often recommend that every compensation statement is reviewed before it goes out. 3 tools that you can use to combat testing fatigue in this scenario are –  Methodically test at least one of every possible scenario and record the result.   Simply compensation statements, limiting the number of possible layouts & views.  Use a tool other than BIRT such as Word. Cost: The report and pdf design used to create compensation statements should be evergreen, meaning that they work year after year without minimal updates to the report or pdf layout. Only less than 10% of the time have I seen this result. Companies are typically using BIRT layouts that require many updates each year or the report incorrectly prints when used to print compensation statement history. BIRT is a free product but costly in terms of services and hours. Complexity: Corrections to compensation statements can be difficult. Imagine that you have already released compensation statements and notice a blank row in one employee’s statement. The BIRT developer is contacted, and it takes them a few hours to repair. Then the statement is fixed but a change in coding may affect other compensation statements; you can only be certain with more testing. A great alternative to BIRT generated compensation statements is to store PDFs in the Worker Document’s section of Workday. You can run Advanced Compensation in Workday, export Workday reports with awards to Excel, populate into Word, and then mass load PDFs into workday. This simple process enables easy corrections, customization, and allows the HR team to easily manage the process rather than relying on partnership with HRIS or IT. I hope that these very specific problem analyses and suggestions help you in your next Workday Compensation Review.  Stay tuned for our next article in 2 weeks. Click ‘Subscribe’ on your way out to receive it directly.

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