A Preview-Only Regression Three Weeks Before Go-Live
An HCM administrator supports Production, a Sandbox used for configuration, and Preview. The new monthly release has landed in Preview but not yet in Production or Sandbox. A calculated field used by the payroll export now returns blanks for roughly 3% of workers in Preview; the identical field returns correct values in Sandbox. Meanwhile, a contractor changed a condition rule on the job requisition business process in Production last month. Requisitions now route to the wrong approver, and nobody can identify who made the change or when. The company has no documented change log, and go-live for a new pay group is three weeks away.
1. How do you diagnose the blank calculated field in Preview without changing Production configuration?
Read the worked answer
First, characterise the 3%. Blanks are not random - find the shared attribute. Build a report in Preview listing the affected workers with their job count, worker type, location, and pay group. The usual suspects are workers with more than one job, workers on leave, and workers whose data sits on an instance type the field no longer resolves.
Second, compare the same workers across tenants. Run the same field against the same worker list in Preview and Sandbox. Same workers, different results, same configuration - that isolates the release as the variable, which is the only thing that changed.
Third, read the release notes for the objects the field depends on. Preview exists to surface exactly this. If a delivered field, lookup, or instance behaviour changed, the calculated field may be resolving against something that is now empty.
Fourth, raise a Workday case early with the worker IDs and both outputs. Three weeks is not long; a case opened late does not get resolved in time. Do not rewrite the field in Production to compensate before you know the cause - you will be fixing a symptom that disappears after the release, leaving a wrong field behind.
Contingency: confirm the payroll export can be run against a known-good field if the release rolls out with the defect. That is a decision to make now, not on release weekend.
2. The requisition condition rule was changed in Production and no one can say who did it. What can you actually recover, and what should be put in place?
Read the worked answer
Be honest about the recovery ceiling. Audit trail is not retroactive. If auditing was not enabled on that business object when the change was made, there is no record of the change, the user, or the timestamp - and no amount of investigation will produce one.
What may still exist: the requisition business process instances that started routing differently, which date the behaviour change to a window even if not to a person; the contractor's case and engagement history; any sign-on or activity records covering access to the tenant; and the current state of the rule itself, which tells you what changed even if not who.
What to put in place - this is the real answer:
- Enable audit trail on configuration business objects, starting with business process definitions and condition rules. Deliberately chosen, not enabled everywhere - auditing everything has its own cost and noise.
- Reduce the population who can edit business process definitions to a named few. A contractor with BP edit rights in Production is the finding here, not the individual change.
- Separate build from operate. Configuration changes reach Production through a reviewed path with a change record, not by direct edit.
- Keep a change log that is not Workday. A dated list of who changed what and why, reconciled against tenant activity, is the only durable answer to 'when did this change.'
Immediate fix: correct the condition rule, then re-test routing on a sample of requisitions before declaring it resolved.
3. Given the release timing and the three-week go-live, sequence the work. What do you do with Sandbox?
Read the worked answer
Key constraint: Sandbox is still on the old version. Fixing anything in Sandbox right now builds against code that will be replaced at release weekend. You would be validating a fix in the wrong environment and calling it done.
Sequence:
- Reproduce and file in Preview now. Preview is the only environment where the new code exists. Diagnose there, escalate there, and get the case in while there is runway.
- Do not refresh Sandbox yet. A refresh will overwrite whatever test data and config the team is currently using, and it does not get you the release any sooner. Refresh is a tool for aligning config with Production, not for getting new code.
- Plan regression testing for the weekend after Production receives the release. That is the first moment Sandbox matches Production's code. Book the testers now - a regression plan with no testers on the calendar is a plan that doesn't happen.
- Do not push the new pay group configuration into Production in the days immediately before release weekend. A change made in that window is untested against the release, and if something breaks you will not know whether it was the release or your change.
- Set the go/no-go decision date inside the three weeks, not on go-live day. The decision should hinge on whether the calculated field defect affects the pay group being launched - if it does, delay; if the affected 3% is outside that pay group, proceed with a documented caveat.
What to avoid: refreshing Sandbox from Production to 'get a clean baseline' mid-diagnosis, which destroys the comparison you are relying on.