14.1 Semi-Annual Release Cadence, Preview Tenants & Feature Opt-In

14.1 Semi-Annual Release Cadence, Preview Tenants & Feature Opt-In

Quick Answer: Workday delivers major platform innovations through a semi-annual release cadence designated purely by calendar year and release number — R1 (Spring / March) and R2 (Fall / September), as in Workday 2025R2 and Workday 2026R1. Workday does not assign marketing codenames to releases; the numeric designation is the official name. Five weeks prior to production deployment, Workday provisions the new code into Preview tenants (such as Sandbox Preview), enabling customers to execute rigorous regression testing across critical business processes, custom reports, and integrations. Enhancements are categorized into Automatically Available (instantly active), Setup Required (requires administrative configuration), and Opt-In (explicitly activated via the Maintain Feature Opt-Ins task). Configuration changes validated in Preview are subsequently migrated to Production using Object Transporter (OX) or Configuration Packages.

---

The Multi-Tenant SaaS Release Model

Legacy enterprise resource planning (ERP) platforms historically subjected organizations to painful, multi-year upgrade cycles. Upgrades required code recompilation, complex database schema transformations, expensive consulting engagements, and extensive custom code refactoring. Consequently, enterprises routinely operated on software versions that were five to ten years out of date, creating fragmented ecosystems.

Workday eliminated this paradigm by architecting a multi-tenant cloud architecture operating on a single, unified codebase. In Workday:

1. Unified Versioning: Every customer in the Workday ecosystem operates on the exact same software version simultaneously.
2. Zero Database Migrations: Data is abstracted through an in-memory object-oriented data model. Customer data structures do not require relational schema alters, index rebuilds, or database table migrations during software updates.
3. Continuous Maintenance vs. Major Releases: Workday applies minor bug fixes, regulatory tax compliance updates, and non-disruptive service updates during weekly service windows (typically Saturday early morning). Strategic innovations, architectural overhauls, and significant user interface (UI) enhancements are bundled into semi-annual major releases.

---

The Semi-Annual Release Cadence (R1 & R2)

Workday structures its release roadmap around two predictable semi-annual milestones each calendar year:

• Release 1 (R1): Target deployment in March (Spring release, e.g., Workday 2026R1, which reached Production on 14 March 2026).
• Release 2 (R2): Target deployment in September (Fall release, e.g., Workday 2025R2, which reached Production on 20 September 2025).

+---------------------------------------------------------------------------------------------------+
|                                 SEMI-ANNUAL RELEASE TIMELINE                                      |
+---------------------------------------------------------------------------------------------------+
 Week -5                Week -4                Week -2                Week 0            Week +2
    |                      |                      |                      |                 |
    v                      v                      v                      v                 v
+-----------+        +------------+        +-------------+        +-------------+    +-------------+
|  PREVIEW  |------->| REGRESSION |------->| INTEGRATION |------->| PRODUCTION  |--->| POST-CUTOVER|
|  DELIVERY |        |  TESTING   |        |  END-TO-END |        |   CUTOVER   |    |  STABILIZE  |
| (5 Wks In)|        | (Core BPs) |        | (Downstream)|        | (Downtime)  |    | (Opt-Ins)   |
+-----------+        +------------+        +-------------+        +-------------+    +-------------+

The 5-Week Preview Window

Exactly five weeks before a major release is cut over to Production, Workday refreshes the Preview tenants with the new release codebase. This 5-week window is the foundation of enterprise release governance, giving administrators, analysts, and integration leads sufficient runway to inspect, test, and prepare.

Tenant Landscape During the Release Cycle

To manage testing without impacting daily operations, Workday provisions distinct tenant types that behave differently during the release window:

Exam Tip: Remember that during the 5-week release window, your Sandbox tenant remains on the current production release code, while your Sandbox Preview tenant is on the new release code. This deliberate separation allows normal daily production support testing to proceed unaffected in Sandbox while release testing occurs in Sandbox Preview.

---

Release Feature Classification Framework

Every enhancement or modification introduced in a Workday major release falls into one of three administrative delivery classifications. Understanding these classifications is critical for both the certification exam and daily tenant administration.

+-----------------------------------------------------------------------------------------+
|                               FEATURE CLASSIFICATION                                    |
+-----------------------------------------------------------------------------------------+
          |                                  |                                   |         
          v                                  v                                   v         
+-----------------------+          +--------------------+              +--------------------+
| AUTOMATICALLY AVAIL.  |          |   SETUP REQUIRED   |              |       OPT-IN       |
| - Default ON          |          | - Code present     |              | - Explicit toggle  |
| - Zero configuration  |          | - Dormant in UI    |              | - Feature Opt-Ins  |
| - Immediate UX impact |          | - Requires BP/Sec  |              | - Evaluated safety |
+-----------------------+          +--------------------+              +--------------------+

1. Automatically Available (Default On)

• Operational Mechanics: These features are activated automatically in all customer tenants the moment the code is applied. They require no administrative configuration or security policy changes to become functional.
• Examples: Visual interface styling updates, optimized search algorithms, accessibility enhancements, performance accelerations in the Report Writer engine, or updated delivered system icons.
• Testing Impact: Because these features cannot be disabled, the release team must evaluate them in Sandbox Preview to assess their impact on end-user experience, train help desk staff, and update standard operating procedure (SOP) documentation before production cutover.

2. Setup Required (Configurable)

• Operational Mechanics: The code for the feature is delivered to the tenant, but the capability remains dormant until administrators actively configure it.
• Configuration Steps Required: Typically requires modifying a Business Process Definition (adding an approval or action step), granting permissions on a Domain Security Policy, enabling a tenant setup checkbox, or establishing a new validation condition rule.
• Examples: A new automated step in the Hire business process, a new configurable compensation allowance calculation rule, or an enhanced talent review matrix layout.
• Testing Impact: The organization has total control over when—or if—to adopt these features. They can be tested in Sandbox Preview and scheduled for rollout months after the major release.

3. Opt-In Features

• Operational Mechanics: Workday provides advanced or transformative capabilities under an Opt-In model. These features remain completely inactive until an administrator explicitly navigates to the Maintain Feature Opt-Ins task and toggles the feature to enabled.
• Lifecycle Progression: Opt-in features allow early adopters to trial major functional changes. In many cases, Workday designates a feature as Opt-In for one or two releases before transitioning it to Setup Required or Automatically Available in a future release cycle.
• Deactivation Rules: Some opt-in features can be toggled off if issues arise, while others represent permanent one-way architectural upgrades that cannot be reversed once tenant data has been committed against them.

Comparison Table: Feature Delivery Classifications

---

Release Administration & Analysis Tools

Workday equips tenant administrators with built-in analytics and reporting tools to evaluate release contents and plan their testing strategy.

What's New in Workday Report

The What's New in Workday report is the primary operational reporting tool used by administrators during the release cycle. Executable directly in the tenant, it allows filtering of all release items by:

• Functional Area: (e.g., Human Capital Management, Compensation, Absence Management, Recruiting, Security).
• Delivery Classification: (Automatically Available, Setup Required, Opt-In).
• Product Category: (Mobile, Core, Analytics, Integrations).
• Configuration Effort Level: High, Medium, or Low.

Feature Release Guide & Workday Community Release Center

Outside the active tenant, administrators leverage the Feature Release Guide on Workday Community. The Release Center provides:

• Release Schedule & Key Dates: Detailed timelines for Preview delivery, weekly Preview updates, and production cutover windows.
• Detailed Release Notes: Deep technical explanations of code modifications, business object model updates, and API version increments.
• Release Readiness Webinars & Demos: Product management walkthroughs of high-impact changes.

---

Structured Regression Testing in Sandbox Preview

A disciplined regression testing program ensures that existing business operations continue without interruption following production cutover. Testing must focus on four foundational pillars:

+---------------------------------------------------------------------------------------+
|                           FOUR PILLARS OF REGRESSION TESTING                          |
+---------------------------------------------------------------------------------------+
          |                           |                          |                      
          v                           v                          v                      
+-------------------+       +-------------------+      +-------------------+    +-------------------+
| BUSINESS PROCESS  |       |    INTEGRATION    |      |  CUSTOM REPORTS   |    | SECURITY POLICIES |
| - Hire / Promote  |       | - Payroll Outbound|      | - RaaS Endpoints  |    | - Role assignments|
| - Terminate       |       | - Benefit Inbound |      | - Exec Dashboards |    | - Domain perms    |
| - Comp Changes    |       | - Core Connectors |      | - Calculated Field|    | - Constrained BPs |
+-------------------+       +-------------------+      +-------------------+    +-------------------+

1. Critical Business Process Pathways

Test high-volume, critical employee lifecycle business processes from initiation through final approval:

• Hire / Onboarding (verify step routing, document generation, and notifications).
• Change Job / Transfer / Promotion (verify compensation defaulting and approval chains).
• Terminate Worker (verify severance calculations, access revocation dates, and asset recovery).

2. Upstream and Downstream Integrations

Integrations represent the highest operational vulnerability during a release. Testing priorities include:

• Payroll Extracts (Core Connector / Cloud Connect): Validate that outbound worker demographic and compensation changes generate identical file layouts without schema deviations.
• Benefit Carrier Feeds: Confirm EDI / ANSI 834 files format correctly.
• Report-as-a-Service (RaaS) Web Services: Verify external middleware (MuleSoft, Boomi, Workday Studio) can authenticate, query, and parse payloads without namespace or XML parsing errors.
• Integration Test Endpoint Caution (Exam Watchpoint): Never point Sandbox Preview integrations to live, external production endpoints (such as production third-party payroll engines). Always route integration test traffic to vendor staging or mock endpoints.

3. High-Impact Custom Reports & Calculated Fields

• Run top-tier executive dashboards and composite reports to confirm execution runtimes have not degraded.
• Verify complex nested calculated fields (such as multi-level Extract Single Instance or Evaluate Expression fields) return expected values against current data.

4. Configurable Security & Role Permissions

• Confirm that role-based and user-based security group assignments continue to govern object and field visibility accurately.
• Validate that newly delivered securable items in Domain Security Policies have not altered baseline user access.

---

Configuration Migration Tools: Object Transporter & Configuration Packages

When administrators configure new features or resolve issues in Sandbox Preview, that configuration must be moved into Production. Workday provides specialized migration tools to eliminate manual re-keying.

1. Object Transporter (OX & OX 2.0)

Object Transporter (OX) is an administrative utility that packages and migrates Workday configuration objects between tenants.

• Supported Objects: Custom Reports, Calculated Fields, Business Process Definitions, Custom Validation Rules, Condition Rules, and Integration Systems.
• XML Definition Transfer: OX extracts the underlying XML definitions from the source tenant (e.g., Preview) and deploys them into the target tenant (e.g., Sandbox or Production).
• Dependency Tracking: OX inspects related object dependencies (for example, verifying that all custom calculated fields referenced within a custom report exist in the target tenant before committing the migration).

2. Configuration Packages (Workday Solutions)

For large-scale enterprise deployments, Configuration Packages provide advanced lifecycle management:

• Grouping Multi-Domain Configurations: Bundles hundreds of related configuration items into a single, cohesive deployment package.
• Validation & Comparison Reports: Generates pre-migration difference reports that highlight schema discrepancies, missing security permissions, or naming conflicts between source and target tenants before deployment occurs.
• Rollback & Version Control: Tracks deployment history, allowing audit visibility into who promoted each configuration package and when.

---

Certification Pitfalls & Common Exam Traps

1. The Sandbox vs. Preview Code Trap: Exam questions often ask: "During week three of the semi-annual release window, in which tenant can administrators test the new release features against production-like data?" Candidates frequently choose Sandbox. The correct answer is Sandbox Preview. Sandbox remains on the current production code to support day-to-day operations.
2. The Mandatory Opt-In Trap: A question may claim that Opt-In features automatically activate upon production cutover if not manually disabled. This is false. Opt-In features remain inactive until an administrator explicitly enables them using Maintain Feature Opt-Ins.
3. Integration Live Endpoint Hazard: Scenarios frequently describe an integration failure where test benefits data overwrote live carrier records. The error was failing to redirect endpoint URLs in the Preview tenant away from production vendor servers.
4. The Release Codename Trap: Distractors sometimes attach an invented codename to a release ("Workday 2025R2 Scout"). Workday identifies major releases only by year and release number — 2025R1, 2025R2, 2026R1, 2026R2. If an option supplies a codename, it is fabricated.
5. OX Data vs. Configuration Trap: Object Transporter migrates configuration definitions (such as report layouts, calculated fields, and business process definitions); it never migrates operational worker instance data (such as employee records, payroll results, or journal lines).