An approval step still pointing at someone who left two comp cycles ago
At a logistics company I worked with last year, the Compensation Review business process still had its fourth approval step routed to a manager named Dana Ruiz. Dana left the company in March, two comp cycles before anyone caught the routing problem. The step didn't error out. Workday's business process framework generally reassigns an orphaned step to the requester's manager or an escalation contact, so approvals kept moving somewhere. They just weren't landing with anyone who had grade authority over the increases they were approving. A VP two levels removed from the actual teams had been clearing 41 merit increases every cycle, whatever showed up in his queue, because nobody had gone back into the approval chain and swapped the named worker for the role.
Nobody sat down and decided the VP should be the one approving those increases. The rule was written years earlier for a specific person rather than a position, and it survived the annual rebuild because that rebuild, in most tenants, is a copy of last cycle rather than a fresh design. The new plan year inherits the old plan's structure. Unless someone opens each screen and checks it against who actually holds each role today, whatever was true last year quietly becomes true again this year, with nobody's name attached to the decision to keep it.
Why last year's configuration survives without anyone approving it
Comp cycle configuration drifts for a boring reason: rebuilding a cycle from scratch is slower than copying the last one and adjusting the parts everyone remembers to check. HR ops usually remembers to update the merit budget percentage and the plan effective dates. What gets missed is the layer underneath those numbers: the eligibility rules that decide who's even in the population, and the routing that decides who signs off. Those objects don't show up on the checklist because nobody wrote a checklist item for a business process step that still points at a person who transferred to a different cost center.
Turnover on the HR ops side compounds it. The analyst who built last year's cycle may not be the one opening this year's, and if that handoff happened without a written record of what was custom and why, the new analyst has one reasonable move: leave settings alone unless they visibly break. A rule that silently excludes half a division from the eligible population doesn't visibly break anything. It just produces a compensation worksheet that looks a little short, and nobody flags a worksheet that looks a little short until a manager calls asking where her team went. This is the same failure mode covered in an ERP master data governance starter: the rule keeps working, technically, right up until it's tested against reality.
What to diff before the cycle opens
The fix is a three-way comparison, done before eligibility opens, between last cycle's configuration and this cycle's, checked object by object rather than screen by screen.
Start with the compensation eligibility rules attached to each comp package. Every condition rule that filters on cost center or location hierarchy has to be re-tested against this year's org chart, not last year's. The same goes for any rule filtering on worker type or job profile. A cost center renamed during a spring reorg will drop silently out of a rule written against the old ID, and no error fires anywhere. The manager tied to that cost center disappears from the eligible population, and she finds out when her whole team is missing from the compensation worksheet on day one of the review window.
Next, diff the compensation matrix itself, the table mapping grade to increase percentage that drives the guideline a manager sees on the worksheet. Finance resets the merit budget every year, but the matrix underneath it doesn't always get touched with the same care. I've seen a matrix where two grades swapped ranges during a prior year's job architecture project and never got corrected, so a grade nine employee was shown a guideline built for a grade eleven. Compare the full grid, row by row, not just the total budget figure at the top.
Last, pull the Business Process Definition for Compensation Review and read every step. Look specifically for a named worker where a role or a position should sit, and for any step still referencing a supervisory org that no longer exists in this year's structure. Export it, export last cycle's version, and run an actual text comparison rather than trusting memory. This is the same discipline a release checklist for shared solutions applies to any configuration multiple teams depend on, and a comp cycle qualifies. It's also the reconciliation habit payroll teams already use at cutover, covered in payroll cutover reconciliation: compare the before and after state directly instead of trusting that nothing changed.
What a mid-cycle complaint is actually telling you
By the time a manager calls to complain, the drift has already cost someone time. The complaint is data though, and it usually decodes into one of two problems. A message like why has my direct report's increase been sitting for nine days almost always means an approval step is routing to someone who no longer holds the approving role, and the request is waiting on a default escalation that nobody's watching closely. Trace the specific step, not just the queue.
A message like I can't see my team's compensation worksheet at all usually means an eligibility rule filtered someone out based on a cost center or supervisory org that changed since the rule was written. A retired job profile causes the identical failure. The fix in the moment is a manual override to get that manager access before the deadline. The fix that actually matters is correcting the filter in the rule itself, because the override won't exist next year and the same manager will call again. Where automation owners lose the thread covers a version of this same handoff gap outside of HR, and the pattern holds here without much translation: a system kept running while the org underneath it kept changing shape, and the two drifted apart quietly enough that nobody noticed until someone complained.
A change log that replaces next year's guesswork
Every override, every corrected rule, every re-pointed approval step needs to land somewhere more durable than an email thread or a memory. A simple log works: one row per change, with the cycle year, the object changed, the old value, the new value, who made the change, and why. That last column is the one people skip, and it's the one that actually saves the next person's afternoon. This is the same governance habit laid out in Workday Extend governance before the first custom app, just applied to comp cycle configuration instead of custom code: write down what changed and why before anyone forgets, because someone else will need that reasoning after you've moved on.
Workday's own audit trail will tell you a rule changed and when. It won't tell you that the rule changed because the western region split into two supervisory orgs in April, and the eligibility condition needed a second branch to cover the new one. That reasoning lives in someone's head until it doesn't, usually right around the time that person changes roles or leaves. A change log with a reason column is what lets next year's HR ops lead open the tenant, see a rule that looks odd, and understand it in thirty seconds instead of spending an afternoon reconstructing a decision from eighteen months ago.
Before eligibility opens on this year's cycle, pull the Business Process Definition for Compensation Review, list every step that still names a specific worker, and check whether that person holds the role the step assumes. Do the same for the eligibility rules and the matrix, comparing each against this year's org chart rather than trusting that last year's build was correct because nothing broke. That comparison takes an afternoon. Explaining to a VP in week three why her merit budget has been sitting on a former employee's desk takes considerably longer, and it happens in front of people who will remember it at her next review.
