Testing Workday’s twice-yearly releases: a five-week plan for the Sandbox Preview window

Workday does not ask when you would like to upgrade. More than 11,500 organizations run on it^[16], and each feature release reaches all of them on the same date. What you control is how ready you are when it lands. That readiness is built in one place: the Sandbox Preview tenant, during roughly five weeks before each release. This guide is a week-by-week plan for those five weeks, written for the person who signs off the release.

The cadence you test to

Workday ships two feature releases a year, R1 in March and R2 in September^[1]. Before each one, the new functionality is switched on in Sandbox Preview, a copy of your production tenant, during a five-week release preparation window^[4]. Workday Education puts it the same way: preview tenants receive new features about five weeks early, and every tenant type gets the release on the same date afterwards^[5].

The 2026R2 cycle shows the real dates. One Workday customer told its teams that Sandbox Preview would be refreshed from production on Friday, August 14, the window would open on August 15, and the release would reach production on September 19^[6]. Ohio State told users Workday would be offline from 2 a.m. to 5 a.m. that morning while the release was applied^[7]. The next release, 2027R1, follows in March; take its exact dates from the Release Center, not from a blog.

Before the window: the baseline you cannot get back

The most important testing work happens before the window opens. Sandbox Preview refreshes automatically from production only twice a year, once for each release window, and after that refresh it cannot be restored or rolled back^[6]. Anything you wanted to compare against has to be captured first.

• Save a production baseline. Outputs of your most-used custom reports, the latest integration output files, and the pay results for the last completed period.
• Run audit reports in production and fix what they find, then run them again in Sandbox Preview after the refresh. Partners recommend this sequence so the release does not get blamed for problems you already had^[17].
• Read the notes early. Coming Soon notes appear one to six weeks before Preview or production, and most feature notes for a major release publish about a week before Preview^[1],[2].
• Book people. Payroll, benefits and finance testers for all five weeks, and a freeze on non-urgent configuration so a failure points at the release.

Week 1: triage, re-point, smoke test

Run the What’s New in Workday report in Sandbox Preview on day one. Its Setup Effort column is your triage key. Automatically Available means Workday enables the feature in your tenant; Workday’s own advice is to assess the impact and create a test plan. Setup Required means nothing changes until you configure it^[3]. Workday also tells customers to regression test in the Preview tenant^[3].

The report has two blind spots. It carries feature notes only: retirements are in the Release Center and a Retirements dashboard^[2]. And opt-in features, which you can switch on or off for now, become automatically available in a later update and drop off the Maintain Feature Opt-Ins report when they do^[9]. Put all three lists into one triage sheet, and give every Automatically Available item and every retirement a test case or a written reason why not.

Before anyone runs an integration in the refreshed tenant, check where it sends data. One vendor warns that a refresh copies integration endpoint configuration from production along with the data^[14]. Re-point or disable outbound integrations first. If you use Adaptive Planning, check its connection too; a refresh where only one side is connected can mean disabling it or rebuilding the setup^[15].

Weeks 2 and 3: run the suite side by side

Workday’s release guide names the focus areas: key integrations, key business processes such as hires, transfers and payment processing, and critical custom reports^[4]. Kainos adds a practical technique: run the regular Sandbox and Sandbox Preview in parallel with the same inputs and compare the results^[8]. Sandbox runs the current release, so the comparison tells you what the new release changed.

• A test fails only in Sandbox Preview: a release regression. Raise it with Workday Support with tenant, steps and evidence.
• A test fails in both: an existing issue. Log it, but do not let it block the release decision.
• Both pass but outputs differ from the baseline: check it. Report columns, file layouts and rounding drift here.

For payroll, run the pay calculation for the same pay group and period in both tenants and compare gross, taxes and net line by line. Workday’s example Pay Cycle Event already includes Run Payroll Audit and the Payroll Audit Exceptions report^[13]; compare exception counts with your baseline as well.

For security, remember how Workday applies changes. Policy edits stay pending until someone runs Activate Pending Security Policy Changes^[12]. Test access thoroughly after activating, through proxy as real members of each security group, and include tests for people who must be denied^[5],[11].

One more trap: Preview tenants often receive new web service versions, data models and implementation types before other tenants. Configuration that depends on them will not migrate to your other tenants until the release reaches them^[10]. Build those changes after the production date, not during the window.

Weeks 4 and 5: retest, escalate, decide

Workday keeps changing Preview during the window. It patches issues and makes small changes after the release opens^[8], and some features arrive in Preview partway through^[2]. Re-run anything those deliveries touch, and check the Preview date on each What’s New row.

Your go/no-go is not whether the release happens; it will. It is whether you go into production day with known workarounds, communications and job aids for every visible change, and no unexplained release regression on a critical process.

The whole window on one page

The free Workday Feature Release Impact & Regression Plan turns this table into dated tasks from three dates you type in, flags every untested Automatically Available item and retirement, and sorts results into release regressions and existing issues. Pair it with the EIB & Integration Test Tracker for the post-refresh checklist, the Security Group & Business Process Test Matrix for access tests, and the Payroll Parallel Reconciliation workbook for the pay calculation compare.

After production day

Smoke test the critical suite in production after the release is applied. Then note that Sandbox Preview stops refreshing automatically; when you need a current copy, someone has to request it^[6]. Meanwhile your regular Sandbox keeps refreshing from production at each weekly service update unless an exemption is requested in time, which one customer sets at 8 hours before the update^[6]. Keep test data that matters out of tenants that reset.