Workday Release Readiness: The Complete R1 & R2 Guide
Workday R1 in March and R2 in September deprecate objects, rename fields, and shift default behaviour. Most tenants accumulate three to five undetected regressions per release cycle. This is the complete pre-release audit playbook — what to check in Preview, what to test before promotion, and how to catch every regression before update weekend.
Why a release audit is non-optional
Workday publishes the 'What's New' guide and the 'Release Notes' for every R1 and R2. Both documents enumerate hundreds of changes. Reading them is the start of release readiness; auditing your tenant against them is the rest of it. Without a pre-release audit, you are betting that none of the deprecations affect your specific configuration. In a tenant with 1,000+ calculated fields and 200+ integrations, that bet loses every cycle.
The five categories every release touches
- Calculated fields referencing soon-to-be-deprecated objects or fields.
- Business process steps using changed step types or default routing.
- Integrations using web services with changed response shapes.
- Security policies on domains where defaults are changing.
- Custom reports using deprecated data sources or fields.
The Preview promotion playbook
Workday gives you Preview 4–6 weeks before each release goes to production. Use it. Run the full scan in Preview as soon as it's available. Compare the findings to your last production scan — anything new in Preview is a release-induced regression you have weeks to fix instead of an after-the-fact incident. Re-run integrations in Preview against a sandbox of the downstream system. Spot-check business processes by initiating one transaction per BP type.
The seven incident classes that repeat every release
- Calculated field referencing deprecated object → report breaks.
- Business process step referencing renamed field → BP fails to initiate.
- Integration response field renamed → downstream system gets null.
- Default security policy change exposes new domain → unintended access.
- ISSG missing newly added domain → integration fails authentication.
- Custom report uses removed data source → report errors out.
- Studio integration uses deprecated step type → integration fails to compile.
Building a release calendar that survives organisational change
Workday publishes R1 and R2 release dates well in advance, but the internal readiness calendar built around those dates is where most organisations lose the thread. The calendar needs to survive a change of HRIS manager, a reorganisation of the IT team, or a busy quarter that pushes 'read the release notes' down everyone's priority list. The way to make it survive is to tie every milestone to a system-generated trigger rather than a person's memory: the day Preview becomes available, schedule the pre-release scan automatically. The day the scan completes, generate the comparison report against the last production baseline automatically. The day the comparison report shows new findings, open tracked tickets automatically rather than relying on someone reading a PDF and remembering to act on it.
Organisations that treat release readiness as a checklist owned by one named individual are one personnel change away from a release-cycle incident. Organisations that treat it as a system-triggered workflow survive turnover because the process does not depend on any single person's attention span in a given week.
Reading Workday's release notes efficiently
The 'What's New' document for a typical R1 or R2 release runs to several hundred pages covering every functional area of the platform. Reading it cover to cover is not a productive use of anyone's time, and most HRIS teams do not have the headcount to do it properly regardless. The efficient approach is to filter by functional area relevant to your tenant's active modules first — if you do not use Workday Adaptive Planning, skip that section entirely — and then within your active modules, filter specifically for the words 'deprecated,' 'retired,' 'default behaviour change,' and 'removed.' These four terms flag the changes most likely to break something silently, as opposed to feature additions that are opt-in and therefore low risk if ignored.
Cross-reference the deprecation list against your own tenant's calculated field 'Where Used' reports and integration mapping documentation before the release goes live, not after. This is the single highest-leverage fifteen minutes of the entire pre-release process, and it is the step most commonly skipped under time pressure.
The Preview tenant refresh trap
A subtle but common failure mode: teams assume their Preview tenant already reflects production configuration accurately, run their pre-release tests against it, sign off, and then discover post-go-live that a configuration change made in production during the Preview testing window was never reflected in Preview because the Preview refresh happened before that change was made. Workday refreshes Preview from production on a schedule tied to the release cycle, not continuously. Any production configuration change made after the Preview refresh and before go-live is untested against the new release.
The fix is procedural: freeze non-critical production configuration changes during the Preview testing window, or if a change is unavoidable, replicate it manually in Preview and retest the affected area before signing off. Teams that skip this step are testing a tenant that no longer matches what will actually go live.
Coordinating release readiness across a shared-services or multi-tenant environment
Organisations running multiple Workday tenants — common after M&A activity, or in shared-services models where a parent company hosts subsidiary tenants — face a multiplied version of the release readiness problem. Each tenant has its own configuration surface, its own integration set, and potentially its own Preview refresh schedule if tenants are not fully co-managed. A release regression pattern found in one tenant (say, a calculated field referencing a deprecated object) is highly likely to exist in sibling tenants that were configured from a shared template, but there is no guarantee anyone checks.
The efficient model here is to run the pre-release scan against every tenant in the portfolio on the same day Preview becomes available, and specifically cross-reference findings across tenants — if Tenant A has three calculated fields at risk from a given deprecation, search Tenant B and Tenant C for the same field names before assuming they are clean. This turns what would otherwise be N independent audits into one audit whose findings inform the others.
Post-go-live monitoring: the first 72 hours
Release readiness does not end when the update goes live on production — the 72 hours immediately following go-live are when latent issues that survived Preview testing surface under real production load and real edge-case data that a test scenario did not cover. Establish a heightened monitoring window: run the integration health report every four hours instead of the normal weekly cadence, watch the Business Processes In Progress report for a spike in stalled transactions, and keep the HRIT team's on-call rotation aware that this is an elevated-risk window rather than business as usual.
Most undetected regressions surface within this window because payroll runs, benefits enrolment triggers, and month-end reporting cycles are what actually exercise the parts of the configuration that a manual Preview walkthrough does not reach. A calculated field that only gets referenced during quarter-end bonus calculation will not surface an error during a Tuesday afternoon Preview test in the second week of the cycle — it will surface on the day it actually runs.
Documenting regressions for the Workday community and support case
When a scan surfaces a genuine release-induced regression — not a misconfiguration on your side but an actual behaviour change that Workday's own release notes did not fully document — it is worth raising a support case and, where appropriate, posting in Workday Community. Other tenants on the same release are almost certainly hitting the same issue, and Workday's product teams do triage based on case volume and community signal. Document the exact steps to reproduce, the calculated field or BP definition ID affected, and the before/after behaviour with screenshots from both Preview and production. A well-documented case gets a faster response and, in aggregate, improves the release notes for the next tenant that hits Preview after you.
Building institutional memory across release cycles
Every R1 and R2 produces a set of findings, fixes, and lessons that are valuable input for the next cycle six months later — but only if someone captures them systematically rather than letting them live in a Slack thread that nobody can search later. Maintain a running release log: which findings appeared, what the root cause was, what the fix was, and how long remediation took. Over two or three cycles this log becomes genuinely predictive — patterns emerge, such as 'our tenant's custom reports are consistently vulnerable to data source deprecations because the reporting team never migrated off the legacy data source X' — and that pattern becomes something you check proactively in every future Preview window rather than rediscovering the hard way each time.
Aligning release readiness with change advisory board processes
Many enterprise IT organisations run a formal change advisory board (CAB) process for any production change with operational risk, and Workday releases — despite being vendor-managed rather than internally initiated — should be brought into that same governance rhythm rather than treated as exempt because 'Workday controls the timing.' Present the pre-release scan findings, the remediation plan for any at-risk configuration, and the post-go-live monitoring plan to the CAB in the same format used for any other production change, with an explicit go/no-go recommendation from the HRIT team. This accomplishes two things: it gives other stakeholders (security, finance, internal audit) visibility into a change that materially affects systems they rely on, and it creates a documented decision trail that is valuable evidence if a release-induced incident does occur despite reasonable preparation.
Organisations that skip this step because 'it's just a Workday update, not a real change' are treating semi-annual mandatory platform updates with less governance rigour than a discretionary internal system change, which inverts the actual risk profile — a Workday release touches every functional area of the tenant simultaneously, whereas most internally initiated changes are scoped far more narrowly.
Training end users ahead of feature-level changes
Not every release finding is a technical regression — some of the most disruptive release-cycle problems are user-facing feature or UI changes that Workday introduces as a default behaviour shift, which technically work correctly but generate a flood of help desk tickets because end users encounter a changed screen, a relocated button, or a renamed field with no warning. Reviewing the release notes specifically for UI and default behaviour changes affecting high-traffic worker- or manager-facing transactions (time off requests, expense reports, open enrolment) and building a short communication — an email, an intranet post, a one-slide visual — ahead of go-live measurably reduces help desk volume in the days immediately following release.
This is a change management task rather than a technical one, but it belongs in the same release readiness calendar as the technical scan, because the two failure modes (a technical regression and a user confusion spike) draw on the same limited HRIT support capacity in the same 72-hour window, and pre-empting one frees capacity to respond faster to the other if it occurs.
- Identify UI or default behaviour changes affecting high-traffic transactions from the release notes.
- Draft a short, plain-language communication for affected worker or manager populations before go-live.
- Brief the help desk team on expected question types so first-line support can resolve without escalation.
- Track help desk ticket volume for the 72 hours post-release as a release health signal alongside technical monitoring.
Frequently asked questions
How far in advance does Workday open the Preview tenant before a release?
Typically 4–6 weeks before the production release date, giving customers a defined testing window against the new release code.
Should we test every integration in Preview or only the critical ones?
Test every integration that writes to or reads from a system with financial or compliance impact at minimum; ideally test the full inventory since Preview testing is low-cost compared to a production incident.
What is the single most common cause of release-induced payroll incidents?
A calculated field or business process condition referencing an object or field that was renamed or deprecated in the release, producing null or default values that payroll processes without erroring.
Can Yoetz.ai run automatically against Preview the moment it opens?
Yes — the scan can be scheduled to trigger against Preview as soon as it becomes available and produce a diff report against your last production baseline.
Who should own the release readiness calendar if the HRIS manager role changes hands mid-cycle?
Ownership should sit with the role, not the individual, with the calendar and its triggers documented and system-generated so a transition does not require re-learning the process from scratch.
Should CAB approval be required before a Workday release goes live in production?
Best practice treats it the same as any other production change, requiring a documented go/no-go decision informed by pre-release scan findings, even though the release date itself is set by Workday rather than the organisation.
Continue reading
Find out what's broken in your tenant
Free first scan. Read-only access. Results in under 2 hours.
Start Your Free Scan