Five Weeks To Test Workday. And It Changes Every Week Inside Them.
AI agents that test Workday HCM, Financials and Payroll by intent instead of selectors — so the same suite runs on Sandbox and Sandbox Preview, as every persona, after every weekly service update.
2026R1
Preview ran 7 Feb – 14 Mar
2026R2 preview
Five-week window · you are here
2026R2 live
Production go-live
2027R1
Next feature release
Five Weeks To Test A Release That Keeps Changing Underneath You
Workday keeps shipping into Sandbox Preview across the whole preview window, and refreshes your Sandbox out from under you every week.
Five Weeks, And The Target Keeps Moving
The preview window is five weeks, but Workday keeps shipping into Sandbox Preview every week inside it — not just on day one. A suite you certified in week one is testing different software by week four.
Your Sandbox Refreshes Itself Weekly
Sandbox is automatically refreshed from Production during the weekly service update unless someone files a refresh exemption at least eight hours beforehand. Test data, in-flight business processes and half-finished manual runs go with it.
It Isn't Workday's Code That Breaks
Workday tests its own releases thoroughly. What breaks is your configuration — business processes, condition rules, calculated fields, custom reports and security. Release notes describe the feature, not what it does to your tenant.
Everyone Sees A Different Screen
Workday renders by security. A manager, an HR partner, a payroll administrator and an employee see different pages, actions and fields for the same process — so one pass through a business process proves almost nothing on its own.
Tests That Describe Intent, Not Selectors
TestZeus agents read Workday the way a functional consultant does, and run as whichever persona the step belongs to. Nothing points at an element ID, so a weekly service update has nothing to break.
Three Things Generic Test Automation Cannot Do In Workday
Run The Same Suite On Both Tenants And Diff The Result
The recommended method is to test Sandbox and Sandbox Preview side by side from the same refresh point, so a difference between them is caused by the release rather than by your data. That doubles execution, which is exactly why teams skip it. Agents make the second pass cost nothing but clock time.
Built For Weekly Service Updates, Not Just R1 And R2
Two feature releases a year is the headline; the real cadence is every Friday. TestZeus agents work from intent rather than selectors, so the same suite can run as a smoke test after each weekly service update without anyone rebuilding scripts between releases.
Tested As Every Persona, Not Just As An Administrator
Because Workday's UI is driven by security, coverage means running the same business process as the initiator, the approver and the recipient. Agents impersonate each persona in turn and assert what each one should and should not see — including the reports and integrations that hang off the process.
Across Both Tenants, Out To Your Pipeline
Agents run the same suite against Sandbox and Sandbox Preview, follow the process out into your integrations and reports, and report into your pipeline — with video and network logs captured on every run.
Manual UAT, Scripts, Or Agents
| Manual UAT | Script-based automation | TestZeus agents | |
|---|---|---|---|
| Fits the five-week window | Barely | If nothing broke | Yes |
| Survives weekly service updates | Re-run by hand | Needs repair | No selectors to break |
| Sandbox vs Preview A/B | Twice the people | Twice the maintenance | Same suite, both tenants |
| Multi-persona coverage | One tester per role | Scripted per role | Impersonated in one run |
| Survives a tenant refresh | Data rebuilt by hand | Data rebuilt by hand | Re-run from scratch |
| Evidence for the record | Screenshots by hand | Varies | Video, logs, JUnit |
See It Run On Your Own Instance
Bring one workflow that breaks every release. We will build it as an agent test and run it against your upgrade preview instance.
Frequently Asked Questions
Workday ships two feature releases a year — R1 in March and R2 in September — plus weekly service updates throughout the year. The 2026R1 release went live on 14 March 2026, and 2026R2 opened in Sandbox Preview in mid-August 2026 for production go-live in mid-September. The twice-yearly releases get the attention, but the weekly service updates are the cadence your regression suite actually has to keep up with.
Five weeks. For 2026R1 the preview tenant opened on 7 February 2026 and production went live on 14 March. For 2026R2, Sandbox Preview tenants were updated in mid-August with go-live five weeks later in September. Workday publishes feature documentation shortly before the window opens, so planning can start earlier, but hands-on validation against the new code is confined to those five weeks.
Sandbox mirrors your current production release and is automatically refreshed from Production during the weekly service update. Sandbox Preview runs the upcoming release during the five-week window. Sandbox Preview is not automatically refreshed the rest of the time — a named support contact has to request it — and Workday arranges one automatic refresh at the start of each release preparation window so both tenants start from the same data.
Sandbox is refreshed from a copy of Production during the weekly service update unless a refresh exemption is submitted, and exemptions are typically due at least eight hours before the update starts for your data centre. Anything you staged for testing is replaced. This is the single most common reason manual Workday test cycles lose a day, and it is why suites that can be re-run cheaply beat suites that depend on hand-built data surviving the week.
Yes, and the distinction matters. Workday tests its own code thoroughly, so you are not hunting for platform bugs. You are testing your configuration — business processes, condition rules, calculated fields, custom reports, integrations and security groups — against changed platform behaviour. That is why generic release notes cannot tell you what to test: the risk lives in how your tenant is built.
Prioritise your critical business processes end to end (hire, job change, termination, payroll run, expense and supplier invoice), then custom reports, then integrations, then security. Reports deserve early attention because they break quietly — a report that returns rows still looks like it worked. Run each process as every persona that touches it, since Workday renders by security.
Yes, and it is the most reliable way to isolate release impact. Refresh both tenants from Production at the same point, run an identical suite against each, and compare. Any difference is attributable to the release rather than to data drift. TestZeus agents run the same intent-based tests against either tenant without modification, so the second execution costs clock time rather than another authoring cycle.
No. TestZeus tests are written in plain English and executed by AI agents that work from intent rather than scripted selectors. In Workday this matters more than usual, because the people who know whether a payroll result or a business process routing is correct are HR and finance practitioners, not automation engineers — and a plain-English suite is one they can review and sign off themselves.
Stop Losing Week One To Rebuilding Test Data
2026R2 goes live in September. The preview window is open now.
