Workday ships two feature releases a year, known as R1 and R2, plus weekly service updates in between. Each feature release reaches a preview tenant first, giving customers a window to review new features and test their configuration before production is updated.
The pattern we see most often goes like this. Release notes are skimmed in the first week. Testing starts in earnest in the second half of the window, once the preview tenant is "settled". Most of it is manual. By the last weekend, HR, payroll and finance analysts are working through spreadsheets of test cases, and anything not reached is accepted on faith.
None of that is required by the calendar. It comes from starting late, testing everything with equal weight, and having no automated coverage of the processes that matter most.
- Feature releases
- Two a year, R1 and R2
- Preview
- Preview tenant before production
- Between releases
- Weekly service updates
Start before the preview tenant is updated
Workday publishes feature release information ahead of the preview. That is when planning should happen, not after.
- Read the release content for every functional area you use: HCM, payroll, time tracking, absence, compensation, financials, procurement and expenses
- Separate features that are automatically available from those that need setup or opt-in
- Flag every change that touches a business process you have configured, a security policy, a calculated field, a report or an integration
- Assign each flagged feature to an owner in the business, not just the HRIS team
- Draft the test delta before the preview tenant opens
Workday customers configure heavily. Business process definitions with condition rules, domain and business process security policies, calculated fields, custom reports, EIB loads and custom integrations are where most release issues show up. A feature that works perfectly in Workday's own test tenant can still change who receives an inbox task in yours.
Test business processes end to end
Workday is built around business processes, so regression should be too. A test that opens a worker profile and checks a field tells you little. A test that runs a hire through to the first payroll result tells you a great deal.
The chains worth automating first are the ones where a failure costs the most and is noticed late:
- Hire to retire. Hire, job change, compensation change, leave, termination
- Time to pay. Time entry, approval, payroll input, pay results
- Expense to reimburse. Expense report, approval routing, settlement
- Procure to pay. Requisition, approval, purchase order, supplier invoice
A hire step written in plain language stays readable for the HR partner who owns the process:
Sign in as 'HR Partner'
Start 'Hire Employee' for ''
Set 'Hire Date' to ''
Submit the 'Hire' business process
Check that the 'Inbox' of '' shows 'Propose Compensation'
The last step is the one release changes tend to break. A change to a condition rule or a security policy does not stop the hire. It sends the next task to the wrong person, or to nobody.
Run the preview window in order
Once the preview tenant is updated, run in waves rather than working through a flat list.
- First days. Sign-in, security roles, navigation and critical integrations
- First week. The end-to-end chains above, across every country or company with its own configuration
- Second week. Impacted regression for features mapped to your configuration
- Then. Opt-in features the business wants to evaluate, and a light smoke of untouched areas
This order front-loads the work that needs the longest to resolve. Security and integration problems often involve Workday support or a third party, and those conversations need time.
Do not forget the weekly service updates
The feature releases get the attention, but weekly service updates also change behavior. Running a full regression every week is not realistic. Running a short, fixed plan of the most critical checks is. A one-hour weekly health check over the core chains catches the small changes that would otherwise surface at month-end close or payroll.
Sign off on evidence
Before production is updated, collect the results by business process and by country or company, list the open items with owners, and have a named person accept, accept with actions or hold. A sign-off made on Wednesday with evidence is worth more than one made on Sunday night on instinct.
How Qventis One helps
Qventis One follows the Workday Release Train, including R1, R2 and weekly service updates. Release Intelligence maps each feature to your business processes, security policies, calculated fields and integrations through the App Model. The Qventis Engine runs the test delta in execution waves in the preview tenant, Test Selector plans cover the weekly health check, and Quality View gives a release acceptance decision by business process and cohort. Book a demo to plan your next feature release.