Why a step didn't fire, or ran when it shouldn't
A business process step that doesn't run, a notification that never sends, or a validation that doesn't block the event usually comes down to one of three separate mechanisms, not one "condition rule" system: an entry condition that decides whether the step runs at all, a routing restriction that narrows who can act on a step that did run, or a validation condition that blocks or warns on exit. Each is configured differently and fails differently, so the first move is naming which one is missing.
If the whole step vanished from the process, look at its entry condition. If the step ran but nobody could see it or approve it, look at the step's security and its routing restriction. If people can still complete the step even though data looks wrong, or the event gets stuck saying it can't proceed, that's a validation condition, and its severity — Critical or Warning — decides which.
Entry condition, routing restriction and validation are different rules
An entry condition applies to any step except Initiation. When it evaluates true, the step runs; when it evaluates false, Workday skips the step and moves on. Some Action steps carry a Workday-delivered entry condition you can't edit, and your own conditions run alongside it — Workday skips the step unless every entry condition passes.
A routing restriction doesn't decide whether a step runs at all. It narrows the security group already assigned to that step — for example, excluding the initiator or a prior approver from an Approval Chain. A step with a routing restriction that excludes every available person doesn't disappear; it goes unassigned, which looks like nothing happened but is really a stalled task waiting for someone Workday can't find.
A validation condition lives on Initiation and Action steps and only blocks the event once you set a severity. Set to Critical, the step can't exit until the failing condition rule is fixed. Set to Warning, Workday shows the message but lets the person continue anyway. Workday defaults a new validation condition to Critical, which is why a check meant only to warn people sometimes blocks them instead — read the severity on the business process definition before assuming the rule itself is broken.
What the condition rule reads, and when
A condition rule reads a field on the business object the step belongs to, at the moment Workday evaluates that step — not at the moment you go back and read the event later. Early in an event like a hire, before the pre-hire record has become a worker, a condition rule built on worker-based fields may not resolve the way it would once the person is active, because the record it's checking isn't complete yet.
Workday also warns against selecting the initiator as the source field on an Initiation step's condition rule: since the rule runs before the business process has actually started, that field returns no result. Point the condition at a field on the process's own business object instead. To see the exact values Workday used, open the step's related actions menu and select Reporting > Report Fields and Values, or build a small report from the event and place the same fields the rule checks — that shows what the rule actually saw, not what the record shows today.
AND, OR and "is blank" behave like short-circuit logic
A condition rule can hold several rules joined by And or Or, and Workday stops checking as
soon as the outcome is decided: with And, it stops at the first rule that fails; with Or, it
stops at the first rule that passes. Order the rules most likely to decide the outcome first,
and use parentheses to group mixed And/Or logic — (A and B) or C reads differently
from
A and (B or C), and Workday won't warn you if the grouping is the wrong one.
"Is empty" and "is not empty" comparisons are a common source of a rule that only seems to work. Test the case you expect to trigger the step and the case you expect to skip it, separately — a rule that correctly fires for the values you tried can still fail silently for a blank, a default, or a field that hasn't been entered yet at the point the step is evaluated.
Confirm which business process definition actually ran
Workday can hold more than one definition of the same business process: a default definition, and for an organization further down the hierarchy, its own version. Only one applies to a given event, and a definition on a child organization replaces the parent's rather than adding to it. Which one runs is set by the event's initiation date, not its effective date — and if the definition an event should have used had a critical error, was inactive, or wasn't yet effective on the day the event started, Workday falls back to the default definition instead, quietly.
Editing a condition rule, a step condition or the business process definition itself doesn't reach events already in progress. A step-condition change applies from the effective date you choose and only affects events that reach that step on or after that date; an event already running still uses the rules that were in effect when it started. To see exactly which definition an event used, and as of what date, open the event itself and select Business Process > View Definition — not the business process's default listing.
Rule out security before blaming the rule
A step a condition rule correctly triggers can still fail to reach anyone if the security group assigned to that step's action doesn't contain an active user — an unassigned task, not a skipped step. To the person who initiated the event, both look the same: silence. Confirm the group actually has the initiating or approval access the step needs, and that anyone the routing restriction would allow still has an active account with a user ID and password.
A related but separate cause: a change to the business process security policy can remove a person's access to a step already sitting in their My Tasks. The task stays assigned, but they can no longer open it, and someone with the right access needs to reassign it before the process can continue.
Checklist: prove the rule, don't guess at it
- Name the mechanism: entry condition (runs or skips the step), routing restriction (narrows who acts), or validation condition (blocks or warns on exit) — and check its severity.
- Open the event and select Business Process > View Definition to confirm which business process definition, and which effective date, actually applied.
- Run the Rule Tester from the event's related actions menu against the real event to see how each rule, and each And/Or group, evaluated.
- Test each rule inside the condition separately, then the whole condition, then a case meant to fail as well as one meant to pass.
- Pull Reporting > Report Fields and Values on the step to see the field values Workday actually used, not the values on the current record.
- If a step or notification stopped firing only after a recent change, check the step condition's effective date — it doesn't reach events already running.
- If the step ran but no one received it, check the assigned security group for an active member with initiating or approval access, using the Unassigned Tasks report.
Where this connects
Copying a condition rule between tenants has its own failure modes — row order, And/Or grouping, and referenced values all need to survive the move; see the guide on copying Workday configuration between tenants. A condition rule built on a calculated field that returns nothing behaves like a rule reading a blank value; the calculated field returns blank guide covers that case directly. If the step belongs to a business process an Extend app initiates or reads, Extend app or Workday configuration covers which side of that boundary actually owns the fix.
An Extend app that depends on this business process for its own next step needs the process to actually run before there's anything to test. kiweely builds and tests those apps in your tenant, but the condition, routing and validation logic stays in the business process definition, where Workday — not the app — decides whether the step runs.