Take The Mystery Out of Workday Release Preparation

Twice a year, Workday releases a host of additional functionality, existing functionality updates, and deprecation notices for items that will no longer be in use. As Workday is an incredibly large-scale system that touches every aspect of your organization, it is critical to be prepared for the necessary tasks to ensure a smooth release every time. It is also important to understand how to do this in a consistently prescribed manner to ensure success. This blog post will discuss the different types of items being released as well as critical tasks to complete during the five-week release cycle.
The Release Cycle
Workday’s release cycle is a five-week period in which new features and updates are released to all Preview environments but not any others. This allows you to review your existing configuration and processes for five weeks and report any bugs you identify to Workday. Release cycle bugs are treated by Workday with a very high priority. There are three goals to accomplish during these five weeks:
- Current Configuration – Ensure that what worked yesterday will continue to work tomorrow. The most critical component of Preview testing is to ensure that existing configurations and processes are not negatively impacted by the updates that will be pushed out each release. This will be discussed in the week-by-week recommended actions further in this blog.
- Automatically Enabled Items – Within the scope of your Workday SKUs, you will need to review the configuration that will be automatically applied within those areas. While testing those items maps to activities listed in bullet point #1, it is also critical to understand how the user experience may change with these automatic features to update any job aids you may have.
- Setup Required Items – Within the scope of your Workday SKUs, you will want to review new features that require setup and place them on a backlog/roadmap for potential development in the future.
Week by Week Recommendations
Week 1
To facilitate accurate testing, a key recommendation is to request a Sandbox Refresh Exemption for Week 2. At the beginning of Week 1, Sandbox and Preview are refreshed at the same time. By requesting a Sandbox Refresh Exemption for Week 2, you will have two weeks where the data is the same in Sandbox and Preview which is critical for the first stage of testing (Integrations, Payroll, and Settlement).
Lockout ALL users in Sandbox and Preview except Administrators and ISUs. This will ensure that no one accidentally introduces new data to either environment. You will want the data in Sandbox and Preview to be identical during this phase of the release. The lockout should remain for the first two weeks or until the below test items are complete, whichever is sooner:
- Run all Inbound and Outbound integrations in Sandbox and Preview and then compare the results of those integrations. Because all users are locked out from both environments (which prevents the creation of new data), the expected result is that all comparisons yield a zero difference result in Sandbox and Preview. If users are allowed to introduce random test data to either environment, it becomes exceedingly difficult to identify differences between integration runs in the two environments. If the results of your integrations in Sandbox and Preview are different and cannot be traced to an errant user’s entry, report the difference as soon as possible to Workday.
- Run Payroll and Settlement (if applicable based on your purchased SKUs) for all pay groups in both Sandbox and Preview. As with the integration items above, the goal is to have a zero difference between the two environments. If you find that the results are different and are not able to trace them to an errant user’s entry, report the difference as soon as possible to Workday.
Week 2
Continue to run the validations from Week 1. Once those validations are complete, you will want to run the following exception audit reports in both Sandbox and Preview:
- Business Process Exception Audit
- Business Process Policy View Audit
- Business Process Definitions with Integration Steps using Deprecated Fields Audit
- Organization Exception Audit
- Security Exception Audit
- Custom Report Exception Audit
- All Custom Reports with “Do Not Use” Items
- Calculated Field Exception Audit
- Condition Rule Exception Audit
- Condition Rules using Deprecated Fields
- Unfilled Roles Audit
- Integration Exception Audit
The goal of running these reports in Sandbox and Preview is NOT to ensure that the reports are empty during this stage of testing. The goal is to ensure that the data these reports produce is the same between Sandbox and Preview which indicates that the new features and code that is in Preview will not trigger issues in the areas those exception audit reports are auditing. As an aside, it is best practice to run these reports regularly (Monthly or Quarterly) in Production and fix any critical issues, but that is not the goal during the five-week release cycle.
DOCUMENT YOUR COMPARISON RESULTS FOR THESE EXCEPTION AUDIT REPORTS!
It is quite common that auditors will request proof of testing during update cycles so this documentation is a necessary artifact to retain for when they are inevitably requested. If there are differences in the report outputs between Sandbox and Preview, please review those differences to ensure that they will not be breaking any existing configuration (such as a security domain being deprecated or having its access rights altered).
Once this is complete, remove the lockout to allow your testers to begin transaction testing during Week 3 – 5. The sooner the listed Week 1 and Week 2 activities are completed, the sooner you can lift the lockout.
Weeks 3 to 5
These three weeks are reserved for user testing and functionality review which can be broken out into the following categories:
- Transaction Testing – In Preview, you will want to test your critical business processes with a variety of scenarios to ensure that the workflow for those processes is not impacted by the new code introduced to Preview. You will want to test a variety of test scripts for each process. For example, you will want to test more than just hiring one employee and one contingent worker. You will want to test hiring part time, full time, hourly, salaried, US vs. Non-US, etc. workers. This phase of testing is fairly intensive so you must identify testers BEFORE the five-week release cycle begins and obtain a commitment from those testers to dedicate their time to these actions. You can find sample test scenarios and instructions on Community via this link. Report any unexpected issues as a support case with Workday.
- Automatically Available Configuration Testing – Within the scope of your SKUs, you will need to test all automatically available features to ensure that your job aids are up to date and that any automatically available feature doesn’t have a significant bug that will interfere with your operations. Report any unexpected issues as a support case with Workday.
- Setup Required Configuration – Review newly released functionality that will require setup should you choose to enable it in the future and place those items on a roadmap based on priority. The five-week release cycle is NOT the time to fully flesh out these items but rather to include them on a list of interesting features you plan to look at in the future. While this is the least critical step of the release cycle, you will want to make the time to do this. If you do not place these items on a future review list, these new and exciting features will likely be forgotten once the release cycle is complete and your operations return to normal.
Final Thoughts
The semi-annual Workday Release Cycle process can be time-consuming given the volume of tasks that need to be performed, but it does not have to be a confusing process. By following the recommendations above “first time, every time”, you will have a smooth and structured cycle to continually improve upon your Workday investment! And, should you need additional support, Kognitiv is here to help.