Workday R1 and R2 Release Prep: The Pre-Release Audit Checklist

1. 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.

2. Read the 'What's New' guide first

Workday publishes the 'What's New' guide and the 'Release Notes' for every R1 and R2. Read both. Highlight every deprecation, rename, and default change. Map each to the configuration items in your tenant.

3. The Preview promotion playbook

Workday gives you Preview 4–6 weeks before each release. Run a full scan in Preview as soon as it's available. Compare findings to your last production scan — anything new in Preview is a release-induced regression you have weeks to fix.

4. The integration spot-check

Re-run every critical integration in Preview against a sandbox of the downstream system. Validate the response shape against the mapping. A renamed response field shows up as a null downstream value if you don't catch it here.

5. The BP transaction test

Initiate one transaction per material BP type in Preview — Hire, Terminate, Compensation Change, Leave Request. Walk every step to completion. A changed default routing surfaces immediately.

6. The promotion sign-off

Document every Preview test, every fix, and every confirmation. Promote to production with a one-page release readiness attestation. This is your audit evidence and your incident-response baseline.

Aligning release testing with the change advisory board calendar

Many organisations run a separate change advisory board process for broader IT change management that does not automatically synchronise with Workday's own release calendar, which can create a scheduling conflict where the CAB's own review cadence falls awkwardly relative to the Preview testing window. Bring the Workday release calendar to the CAB's own annual planning cycle and request a standing agenda slot aligned to each promotion date, rather than submitting an ad-hoc request each cycle — this reduces the risk of a rushed or skipped CAB review purely because of scheduling friction rather than any substantive concern about the release itself.

Training business process owners to test, not just approve

A common but underappreciated failure mode is business process owners treating Preview testing as a formality to approve rather than an activity to actually execute end-to-end. Provide each domain owner with a short, specific script — the exact transaction to run, the exact expected outcome, and the exact place to note a discrepancy — rather than a generic instruction to 'test your process in Preview.' Owners who are given a concrete script produce measurably more thorough testing than owners given a general reminder, because the ambiguity of what 'testing' actually requires is removed.

Handling Preview environment access and permission delays

Preview environment access itself can become an unexpected bottleneck: security provisioning for testers, especially newly hired or recently transferred staff, sometimes lags behind the Preview opening date, effectively shortening the real testing window for those individuals. Request Preview access provisioning as a standing item at least two weeks before each Preview opening, tied to the same release calendar used for other planning, so access delays do not silently consume days from an already compressed testing window.

Building a release calendar your whole team actually uses

The single biggest failure mode in R1/R2 preparation is not technical — it is calendar mismanagement. Preview access opens on a fixed schedule set by Workday months in advance, yet many teams only start planning when Preview actually lands, leaving 4–6 weeks to compress into whatever gaps exist in already-committed sprints. Build a release calendar at the start of the fiscal year with every Preview open date, feature freeze date, and production promotion weekend marked, and treat the two weeks after each Preview opening as protected time — no other major project work scheduled against the same team members during that window.

Assigning ownership across configuration domains

Release regressions cluster around ownership gaps as much as technical gaps: a business process regression gets caught because the HR business process owner tests it, but a security domain default change gets missed because nobody on the team considers security review part of 'their' release testing responsibility. Assign a named owner for each of the five categories — calculated fields, business processes, integrations, security, and reporting — and make each owner responsible for reviewing the relevant section of the Release Notes, not just running a generic checklist someone else wrote.

Reading release notes efficiently: a triage method

• Pass 1 — skim every heading in the What's New guide and flag anything touching a domain your tenant uses heavily (comp, payroll integration, security groups).
• Pass 2 — for flagged items, read the full description and note the specific object, field, or step type affected.
• Pass 3 — cross-reference each affected item against your tenant's actual configuration inventory (via a scan or a manual export) to determine real exposure.
• Pass 4 — build the Preview test plan only from confirmed-exposure items, rather than testing the entire release note list exhaustively.

Prioritising what to test when time is short

Not every release cycle affords the full 4–6 week testing window in practice — go-lives, unrelated projects, and staff availability compress the real testing time available. When time is genuinely constrained, prioritise in this order: anything touching payroll or benefits integrations (financial and compliance impact), anything touching security domain defaults (data exposure impact), anything touching a business process used by more than 80% of the workforce (Hire, Termination, standard comp changes), and only then move to lower-traffic business processes and reporting.

The role of a configuration inventory in release prep

A release note tells you Workday changed something; it does not tell you whether your tenant is exposed. The only way to answer that reliably is to hold a current inventory of every calculated field, business process definition, integration, security group, and report your tenant actually uses, and cross-reference each release note item against that inventory. Manually maintaining such an inventory is impractical at enterprise scale — an automated scan effectively is that inventory, refreshed on demand, which is why running a scan immediately on Preview opening is more efficient than manually reading through configuration screens.

Coordinating with downstream integration partners

Integrations are the release-readiness category most likely to fail silently, because the failure surfaces in a downstream system your Workday team does not directly monitor. Build a standing communication cadence with every integration partner (payroll provider, benefits carrier, ATS, data warehouse) that includes a heads-up before every Preview testing window and a request for their own change log covering the same period — a downstream system change landing in the same window as a Workday release change compounds the risk and is easy to misdiagnose as 'the Workday release broke it' when the actual cause is on the other side.

Post-promotion monitoring: the first 72 hours

Release readiness work does not end at promotion. The first 72 hours after a production promotion are the highest-risk window for issues that Preview testing did not catch, often because Preview data volumes or edge cases differ from production. Run an automated scan against production within hours of promotion and diff it against the pre-promotion baseline — any new finding in that diff is a candidate release regression, and catching it within the first 72 hours rather than the first help-desk ticket weeks later dramatically reduces both the fix cost and the business impact.

Building the release readiness attestation into your audit evidence

SOX and other compliance frameworks increasingly expect evidence of change management discipline around system updates, not just around custom development. A one-page release readiness attestation — listing what was tested in Preview, what was found, what was fixed, and sign-off from each domain owner — becomes reusable audit evidence with almost no incremental effort if it is built as a standard artefact of every release cycle rather than assembled retroactively when an auditor asks for it.

Preparing sandbox data quality ahead of Preview

Preview testing is only as good as the data it runs against, and a stale or unrepresentative sandbox is one of the quieter causes of missed regressions. If the sandbox refresh predates a significant production change — a new integration, a restructured comp plan, a large headcount change — Preview testing runs against a configuration state that no longer matches production, and issues specific to the newer state go untested. Schedule a sandbox refresh close to each Preview opening date specifically for release testing purposes, rather than relying on whatever refresh cadence exists for general development use.

Coordinating Preview testing across time zones and business units

Large, multi-region tenants face a coordination problem that smaller organisations do not: a business process test that only makes sense from a single region's payroll calendar or a single business unit's approval chain gets tested from one perspective and passes, while the same process fails for a different region's configuration variant. Build the Preview test plan explicitly by region and business unit for any process that has known configuration variants, and assign at least one tester per variant rather than assuming a single successful test run generalises across the whole tenant.

Documenting tester sign-off in a form that survives an audit

A verbal 'looks good' from a business process owner during Preview testing is not evidence of anything by the time an auditor asks for it eighteen months later. Require every domain owner to sign off in writing against a specific, dated test plan, noting exactly what was tested, what was found, and what remediation (if any) was applied before promotion. This is a small process addition during the release cycle itself and a significant asset when SOX or equivalent audit evidence is requested later.

• Capture sign-off per domain owner, per release cycle, tied to a specific dated test plan.
• Record what was tested, what was found, and what remediation occurred — not just a pass/fail flag.
• Store sign-off records centrally so they can be retrieved without reconstructing them from email threads during an audit request.

Handling features that require configuration decisions, not just testing

Not every release item is a pure regression risk — some are opt-in features requiring a genuine configuration decision (enable now, enable later, or do not enable) rather than simple pass/fail testing. Route these to the relevant business owner explicitly and separately from the regression testing workstream, with a decision deadline tied to the feature freeze date, because these decisions frequently get deprioritised behind urgent regression fixes and then missed entirely, leaving a valuable feature unconfigured for another six months by default rather than by choice.

Frequently asked questions

Continue reading

• Release Readiness Guide
• How Workday Releases Break Tenants
• Release Incident Prevention
• Run a free Preview scan