The release that changed your reports over a weekend

On 19 September every Workday tenant took the 2026R2 release: 601 items, 73 of them retirements, applied in place with no opt-out. Your reports now run on changed surfaces. This page is the reporting team’s read, and the re-test that proves what still holds.

RuleTreat every biannual release as a data event: inventory what your reports depend on before it lands, diff their outputs against saved baselines the week after.

Neverassume a report that runs is a report that is right. A retired field or changed surface produces output that looks normal and answers differently.

Six weeks of notes, then one weekend, then your reports run on whatever changed. The re-test below is how the Monday stays quiet.

◆ A release you did not schedulein place, tenant-wide, no opt-out.

Workday updates every tenant twice a year, R1 in March and R2 in September, in place over a single weekend. There is no version to stay on and no window to decline. Whatever the release changes under your delivered reports, calculated fields, and extract paths is changed for you, everywhere, at once.

The 2026R2 feature notes were published on 7 August, six weeks ahead. Most reporting teams meet the release anyway on the Monday after, through a report that renders differently or an integration file that quietly shrank. Status September 2026.

◆ What this release carriesthe counts, as customers report them.

2026R2, per customer change notices	Count
Items in the release	601
Feature improvements	339
Fixes	176
Retirements	73

Largest areas	Items
Financial Management	149
Human Capital Management	115
Platform and Extend	103
Payroll	86

Counts are as reported in customer change notices from Texas A&M’s Workday services team and Ohio State’s release notice; the vendor’s own release notes sit behind the community login. The visible changes cluster in the screens: the home page, tasks, notifications, and the worker profile were redesigned. The dangerous changes are the ones with no screen at all.

◆ The retirement problem73 things left, and the list is behind a login.

A retirement is a field, report, task, or behavior the vendor removed. The full list lives in the gated release center and is updated weekly, which means most teams cannot even enumerate what just disappeared from their tenant, let alone say which of their reports depended on it.

Nothing announces itself. A custom report referencing a retired field does not fail on a stage; it recalculates, omits, or renders around the gap. The only defense is knowing your dependencies before the release and diffing your outputs after it.

◆ The week-one re-testthe control that catches what changed.

Re-test	Against what
Critical custom reports, re-run	Output saved before the release: same filters, row counts and totals compared line by line
Extract and integration outputs	The prior run’s file: row counts, column sets, and checksums, not a visual skim
Calculated fields on those reports	Hand-computed spot checks on known workers, the fields most likely to shift silently
Scheduled deliveries and bursts	Did every schedule fire, reach its audience, and carry the full population
Security-trimmed populations	The same report run as two roles: the trim boundaries are release-sensitive

The baseline is the whole trick: outputs saved before the release weekend are the only ground truth after it. A team that keeps them turns release week into a diff; a team that does not is asking users to notice.

◆ The owned answerthe model that does not move when the tenant does.

History already landed in the owned spine model is untouchable by any release: the release cannot reach your warehouse. The exposure narrows to the extract paths themselves, and the landing check already guards those: tenant counts against landed counts, every run, so a changed extract surface shows up as a number, not a surprise.

That is the standing trade the delivered-versus-owned page describes. Delivered reporting inherits every release, twice a year, forever. The owned model meets the release exactly once, at the extract seam, where it is measured.

Use case

Problem

Biannual releases change delivered reports, fields, and extract behavior in place, and the retirement list is gated, so teams discover breakage through wrong outputs weeks later.

What we build

The owned landed model that releases cannot reach, plus the release-week control: saved baselines, output diffs, and the landing count check at the extract seam.

What you get

Release weekends that end in a diff report instead of user complaints, history that never re-states itself, and one measured seam instead of a thousand exposed reports.

Did 19 September change any of your numbers?

We build the baseline-and-diff control and the owned model releases cannot touch.

Talk to us

Terms on this page

2026R2: Workday’s second 2026 release, applied to production 19 September 2026.
R1 / R2: The biannual release slots: March and September, every year.
retirement: A field, report, task, or behavior the vendor removed in a release.
baseline: Report and extract outputs saved before the release; the ground truth for the diff.
extract seam: The one place the owned model touches the tenant; the only release exposure.
landing check: Tenant count against landed count on every extract run.
release center: The gated vendor site holding the full release and retirement notes.