Workday release review
What Workday release review actually involves
Twice a year Workday ships a feature release to every tenant. Somebody has to work out which of the new features matter to your organisation, who owns each one, and whether anyone needs to change or test anything before it lands. This is what that process looks like in practice, and where it usually goes wrong.
The cadence
Workday delivers two feature releases a year, and weekly service updates in between. The two are not the same thing and should not be handled the same way. Weekly updates are small and mostly invisible. A feature release changes behaviour, adds configuration, and occasionally requires you to do something before it arrives.
Each feature release reaches your Sandbox Preview tenant several weeks ahead of Production. That gap is the entire window in which release review has to happen. It is not generous, it overlaps with whatever else is running, and it arrives at the same time every year whether or not you are ready for it.
Where the feature list comes from
The starting artifact is the What's New in Workday report, delivered inside the tenant. It lists every feature in the release, with its functional area, a description, and metadata about whether it is automatically available or requires setup.
Almost nobody reviews it inside Workday. The near-universal habit is to export it to Excel, because the review is a conversation between several people and a report inside a tenant is a bad place to have a conversation. Once it is a spreadsheet, someone shapes it into what most teams call a heat map.
What a heat map is
A heat map is the delivered feature list plus the columns your organisation actually cares about, with colour applied to mark the things that need attention. There is no standard template. Every consultancy and every customer has their own, which is itself part of the problem.
The columns that recur almost everywhere:
| Column | What it answers |
|---|---|
| Functional area | Whose problem is this? Payroll, Absence, Recruiting, Financial Accounting, and so on. Note that this is your organisation's own bucket list, not Workday's taxonomy, and the two rarely match exactly. |
| Setup required | Does this arrive switched on, or does somebody have to configure it? Usually highlighted when the setup is significant and needs real effort. |
| Training and testing impact | Will anyone need to be told about this, or retrained? Usually highlighted when the training impact is significant. |
| Recommended training | If training is needed, for whom. End users, super users, or both. |
| Owner | The named person responsible for deciding, and for signing off. |
Two things about the highlighting are worth stating plainly, because they are a common source of confusion. First, red on setup and red on training are two independent signals. A feature can be significant setup with no training impact, or the reverse. Reading one as a proxy for the other is a mistake that survives easily, because in some releases the two columns happen to agree on every row. Second, the colour usually carries meaning that exists nowhere else in the file. If the legend is lost, so is the analysis.
Who signs off, and on what
Sign-off is not one decision. For each feature in their area, the owner is really answering two separate questions:
- Is the description accurate for us? Does this feature do what the release note says it does, in our configuration? This is the question that catches genuine surprises, and it is the one most often skipped.
- Does anything need to happen before it lands? Configuration, security changes, communication, training, a regression test.
The person coordinating, usually a PM or a lead consultant, is not answering either question. Their job is to make sure every feature has an owner, every owner has answered, and the answers are collected somewhere before the release reaches Production.
Where it goes wrong
The workbook fans out and comes back divergent
The heat map gets emailed to each owner. Each one edits their own copy. What comes back is several files with the same name and different contents, and someone reconciles them by hand. Every reconciliation is an opportunity to lose an answer.
Nobody can see who has not replied
Silence and agreement look identical in an inbox. The coordinator has to track completion manually, usually in a second spreadsheet, and chasing is the single largest time cost in the whole exercise.
The owner roster drifts
People change roles between releases. Functional area names in the delivered report do not always match the names your roster uses, and the mismatch is usually silent: features simply end up with no owner rather than raising an error.
Features with no owner are found too late
This is the failure that actually costs something. A functional area that nobody has been assigned to does not produce a complaint during review. It produces silence, which reads as completion. The gap surfaces after go-live, when somebody asks why nothing was tested.
Reviewers do not all have tenant access
The people who best understand whether a change matters are not always Workday users. A benefits lead or a payroll manager may have no tenant account at all, which is exactly why the review left the tenant and became a spreadsheet in the first place.
What Workday itself provides
Workday's Adoption Planning Hub became generally available in 2026R1 and is included in every tenant. It lets you create adoption items from the What's New report in bulk, assign them by user and functional area, and track them through a backlog and roadmap. If you are a single customer and everyone who signs off already has the right security domains, it is a reasonable place to run this.
Its limits are structural rather than qualitative. It lives inside one tenant, so there is no across-tenant view for anyone running release review for several clients. And every reviewer needs to be a provisioned Workday user with the relevant domains, which does not help with the benefits lead who has no account.
A practical sequence
- Export the What's New report as soon as the release notes are available, well before Preview.
- Confirm the owner roster first, before distributing anything. Reconcile your functional area names against the delivered ones and resolve the mismatches once.
- Find the unowned areas immediately. This is the highest-value ten minutes in the process and it is usually left to the end.
- Distribute by area, not by file. Each owner should be answering about their own rows and nothing else.
- Track completion continuously, not by asking.
- Separate accuracy from action. "This description is wrong for us" and "we need to configure something" are different findings and should not share a column.
- Keep the result. Next release starts from this release's roster and this release's decisions.
Running one of these soon?
ReleaseSignoff exists to do exactly this, without the workbook round-trip. It is new and nobody is using it yet, so I am looking for a small number of teams to run a release on it and tell me what breaks.