Workday Phase X: The 8 Configuration Checks Every Consultant Should Run Before Go-Live

Phase X implementations — adding Workday modules like Recruiting, Payroll, Learning, or Expenses to an already-live tenant — are where the most avoidable mistakes happen. The initial implementation team has moved on. The AMS team inherits whatever config exists. And nobody has done a proper readiness check before the new module launches. The result is a go-live weekend that quietly ships broken approval chains, ISUs with too much access, and a queue of calculated fields silently returning errors.

1. Business Process Approval Coverage

Every business process routing through the new module needs at least one approval step — not just compensation. On a Recruiting rollout, Offer, Move, Change Job, and Assess Candidate all need a defined approver path. On Payroll, Enter Time and Request Time Off both trigger downstream calculations that should route through a manager. This is the single most common Phase X miss because implementation partners test happy paths and the approval routing gets set up for whoever was configuring at the time — often the consultant themselves. The consultant leaves. The BP still routes to their (now terminated) account. Every transaction stalls until someone digs into the routing.

2. SOD Violations in High-Risk Processes

Adding a new module means new security groups. In the rush to get UAT complete, security groups get created quickly, mapped broadly, and rarely reviewed for segregation of duties. In Phase X, SOD violations show up in specific patterns: a Recruiting security group that can both initiate and approve offers, a Payroll group that can enter and approve time on the same worker, an Expenses group that can submit and approve their own report. These are more common than in initial implementations because the Phase X team is smaller, moving faster, and inheriting a security model that was designed before the new module existed.

3. ISU Account Type Hygiene

Integrations added for a new module frequently get set up under a named user's account for speed — someone runs a Studio integration test on their personal ID and the credential just… stays. That ISU has full HCM domain access it doesn't need. Six months later that consultant offboards, their account is terminated, and every integration for the new module stops working overnight. The fix is basic and boring: every integration credential must be a dedicated ISU account (not a personal one), scoped to only the domains the integration touches. Phase X projects should exit with zero personal-user integration credentials in the tenant.

4. Job Profile Completeness for Recruiting and Talent Modules

If Phase X is Recruiting or Talent Management, job profile descriptions below 70% completeness means the module is broken from day one. Career pathing recommendations rely on structured job profile data. Skills matching relies on it. Illuminate-driven candidate recommendations rely on it. The typical scenario: the client migrated job profiles from a legacy system without descriptions, the implementation team promised to "fill those in during hypercare," and hypercare ended with 400 profiles at 30% completeness. Nothing in the module works properly. Users blame the software.

5. Skills Cloud Population for Career Pathing

Same problem as job profiles, but specifically for Skills Cloud. If Career Pathing or Skills Cloud is part of the Phase X scope, the tenant needs a populated skills taxonomy before go-live — not "we'll build it as we go." Skills Cloud is also the primary Illuminate dependency: agents cannot recommend career moves against an empty taxonomy. Ship Phase X with a sparse Skills Cloud and every AI capability the client bought this module for will underperform for a year while data trickles in.

6. Calculated Field Error State

Calculated fields in error before go-live produce bad data from day one. Phase X frequently introduces new calculated fields that reference objects only present in the new module — a Recruiting-specific tenure calculation, a Payroll-specific gross-to-net check. If those fields have any error state at go-live, they'll return null for every worker in scope, and the downstream reports and integrations will silently drop those rows. These errors accumulate quietly. Nobody sees them until a payroll cycle runs short or a compliance report is missing 30% of the workforce.

7. Unconstrained Security Group Creep

New module means new security groups. Teams often leave them unconstrained for speed during configuration — no organization scope, no cost center scope, no location scope. The intent is always to constrain them "after UAT." UAT ends. Everyone signs off. The security groups stay unconstrained. Once the module is live, an unconstrained Recruiting Coordinator group can see every requisition in the company, not just their organization's — and the audit trail catches up with the client three months later.

8. Open Transaction Backlog

If the tenant already has open transactions or zombie business processes, adding a new module multiplies the problem. Every stale approval in the queue now interacts with new BPs from the new module. Stakeholders who own approvals in the new module can't tell which items are theirs to action. Reports that filter by BP status return inconsistent counts. Clean the backlog before Phase X go-live, not after.

Automating these 8 checks

These 8 checks can be validated manually in 3–5 days of senior consultant time per tenant, or automatically in under 2 hours with Yoetz. See Yoetz.ai for consulting firms for how AMS and implementation teams run Phase X Readiness Scans across their entire client book before every module launch.