2.2 Releases, Adoption, System Testing & Support

One version for everybody

All Workday customers are on the same version. That is what lets Workday ship functionality quickly, and it is also why a platform administrator cannot decline an upgrade. What you can control is which optional features you turn on and how thoroughly you test before the release reaches Production.

Two delivery mechanisms

The distinction drives your workload. Weekly service updates rarely require action but should be scanned - Workday publishes Weekly Service Update Notes on Community detailing the defects fixed each week, so you can react to changes appearing in your preview and production tenants. Feature releases require a planned cycle.

The preview window

This is the timing fact the exam most reliably tests.

During feature release cycles, Workday delivers new features and functionality to preview tenants approximately five weeks in advance of the feature release, if not earlier. At the end of the preview window, Workday delivers the feature release to all tenant types on the same date.

   Week -5              Week -4 .. -1                Release Day
      │                       │                          │
      ▼                       ▼                          ▼
 New release code    Regression testing in       Feature release
 lands in Sandbox    Sandbox Preview:            delivered to ALL
 Preview             run What's New, test        tenant types on
                     critical BPs, reports,      the SAME date
                     integrations, security

Two corollaries worth holding on to. First, there is no staggered rollout you can opt into - every tenant type receives the release on the same day. Second, the preview window is your only opportunity to see your own configuration running on the new code before it is live, which is why the preview tenant is the centerpiece of release preparation.

Preparing: the reports and resources

In the tenant

• What's New in Workday - a report that identifies new features, both automatically available and opt-in. Workday's guidance is explicit: run it in your Sandbox Preview tenant when the release preparation period begins, and again as needed throughout the preview window.
• Adoption Planning Dashboard - part of the Adoption functional area. Its worklets include What's New in the Last 7 Days, What's New in the Last 6 Months, supplemental resources, and adoption items. This is the tool for ongoing adoption rather than a single release event.

On Workday Community

Workday Community is the primary communication tool for all updates - a portal carrying roadmaps, schedules, update and release notes, announcements, webinars, and documentation.

Automatically available versus opt-in

Feature release content divides in two, and the distinction shapes your test plan:

• Automatically available features arrive switched on. You cannot decline them, so your testing question is "does this break anything I already do?"
• Opt-in features require deliberate activation. Your question is "do we want this, and what does turning it on affect?"

Because What's New in Workday flags which category each feature falls into, running it in Sandbox Preview at the start of the preparation window is what turns a large release into a short, targeted test list.

A workable release-preparation process

1. Read the Release Preparation Center and the release notes; identify features touching areas you have configured.
2. Run What's New in Workday in Sandbox Preview and split the output into automatically-available and opt-in.
3. Regression test in Sandbox Preview: your most-used business processes end to end, custom reports whose data sources or fields are affected, integrations, and security policies for changed domains.
4. Evaluate opt-in features against business value and downstream touchpoints.
5. Communicate changes to users, and prepare training or announcements for anything user-visible.
6. Verify in Production after the release lands, since the release reaches every tenant type on the same date.

System testing and system support

The fourth objective in this module is identify processes for system testing and system support, and it is broader than the release cycle.

Testing. Prove changes in a nonproduction tenant before Production. Use proxy to verify what a security group actually experiences - remembering that proxy works in nonproduction environments only, that only unconstrained security groups can be configured with proxy access, and that a proxy session cannot receive notifications, scheduled reports, or integration output. Use the Business Process Configuration Options report before configuring a business process to confirm which options that type even permits.

Support. Workday Community is also the support channel: it is where you raise and track cases, search the Administrator Guide, read Brainstorms, and join community groups. Within the tenant, the Documentation entry in the Worker Profile menu opens the Administrator Guide directly, and the Help link points at your own internal support page - the URL you set with Edit Tenant Setup - System.

Exam habit: when a question describes an unexpected behavior appearing without any configuration change, the intended answer usually involves a Workday-delivered change - check the weekly service update notes or the release notes - rather than a hunt through the customer's own configuration.