3 QA Red Flags in Workday Configuration That Will Cost You at Go-Live

I've conducted QA reviews on dozens of Workday implementations. Across projects of every size and scope, a small number of configuration issues recur with enough consistency that I now treat them as canary-in-the-coal-mine indicators. Spot any of these three and you have a quality problem that's guaranteed to surface at go-live.

Red Flag #1: Business Process Exceptions Without Documented Rationale

Workday's business process framework is powerful. It lets you define approval chains, notification rules, and conditional routing that reflect your organization's actual operating model. But that flexibility comes with a risk: the temptation to create exceptions for every edge case.

Here's what I find alarmingly often in QA reviews: a business process configuration with 15-20 routing rules, each adding an extra approval step, conditional branch, or notification trigger — with zero documentation about why any of them exist.

Why this is a red flag: Every exception to the standard process is a maintenance liability. Workday releases updates twice a year. When your business process has 20 undocumented exceptions and the next release changes how routing conditions work, nobody knows which rules are intentional and which were experimental. The result: processes break silently, and you discover them when a new hire can't get their manager assigned because a routing condition that "seemed like a good idea" nine months ago is now failing in an unexpected way.

What to do about it: Every business process rule should have a documented rationale. Not a novel — one or two sentences explaining the business need. "C-level approvals required for roles with salary > $150K to comply with board delegation of authority policy" — that's a good rationale. "Per Jane in HR" — that's not.

The QA test: Pick three random business process rules in your configuration and ask the configuration team: "Why does this rule exist?" If they can't answer clearly, you have a documentation gap that will become a go-live incident.

Red Flag #2: Calculated Fields With No Test Coverage

Calculated fields are Workday's Swiss Army knife. You use them to derive pay rates, compute tenure, generate eligibility rules, transform data for reporting. They're incredibly useful. They're also incredibly easy to get wrong — and when they're wrong, the error propagates silently through every downstream system that depends on them.

In a recent QA review, I found a calculated field used to determine overtime eligibility for a 500-nurse workforce. The formula looked correct at a glance. But step-by-step testing revealed that when a nurse worked a 12-hour shift that crossed midnight, the calculation double-counted the hours. This error had been live in the system for four months of configuration testing. Nobody caught it because nobody had written a test case that included a shift-crossing-midnight scenario.

Why this is a red flag: If calculated fields aren't tested individually — not just as part of end-to-end process tests but with dedicated unit tests — you're trusting that every formula is correct through hope, not evidence. And in Workday, a wrong formula doesn't throw an error. It silently produces the wrong number. Every time.

What to do about it: Build a calculated field test matrix. For every calculated field in your configuration, document:

• The expected inputs and their ranges
• The edge cases (null values, boundary conditions, cross-midnight scenarios)
• The expected output for each case
• The actual output

Test each field independently before you test it within a business process.

The QA test: Ask your configuration team for their calculated field test matrix. If they don't have one, that's the red flag. If they have one but it only covers happy paths, that's a yellow flag. Only green when it includes documented edge cases.

Red Flag #3: Security Roles Configured Before Design Sign-Off

Workday security is complex. Roles, permission groups, domain security policies, intersection security — there's a lot to get right. And because security configuration is time-consuming, there's a strong temptation to start configuring early, before the security design is fully signed off.

Here's what happens: the implementation team starts building roles based on an early draft of the security matrix. The design evolves through stakeholder reviews. But the configuration doesn't keep pace with the design changes. By the time testing rolls around, what's configured bears only a passing resemblance to what was designed.

Why this is a red flag: Security issues found in UAT are among the most expensive problems to fix. A role configured incorrectly affects every user assigned to that role. It blocks access for legitimate users or — worse — grants access to data or actions users shouldn't have. Fixing it requires reconfiguration, re-testing, and re-certification.

In healthcare, this isn't just an operational problem. It's a compliance risk. Improper security role configuration can expose PHI, violate HIPAA access controls, or fail a Joint Commission audit.

What to do about it: Freeze security configuration until the security design is fully signed off. Then configure from the signed-off design. Then validate the configuration against the design, one role at a time. If you need to start security work early, limit it to understanding the toolset and building frameworks — don't configure actual roles until the design is locked.

The QA test: Compare three roles in your current configuration against their corresponding entries in the signed-off security design. If more than one discrepancy exists per role, your security configuration process needs a reset.

The Go-Live Cost of Ignoring These Red Flags

Each of these red flags has a predictable cost trajectory:

The pattern is clear: the earlier you catch it, the cheaper it is. And these three red flags are reliably detectable before configuration is complete — if you have a QA process looking for them.

A Final Thought

Workday is an incredibly capable platform. But capability is not the same as correctness. These three configuration red flags are among the most common I see precisely because Workday makes it so easy to configure quickly — and speed, in configuration, often masks quality gaps.

The organizations that catch these issues before go-live are the ones that build QA into their implementation process, not just their testing phase. They review configurations, challenge undocumented decisions, and force-test their calculated fields before they go into production.

Your configuration team knows these red flags exist. The question is: do they have a process for catching them?

Twinkle True North Consulting offers targeted QA reviews for Workday configurations — before go-live, during UAT, or as a mid-implementation health check. Our Workday Configuration QA Review ($5,000 one-time) covers all three of these red flags plus a comprehensive configuration audit. [Contact us] for details.