6.2 Creating & Testing Condition Rules

What condition rules do

Condition rules allow you to configure a business process to behave differently in certain situations. The rules use logical statements connected to data in Workday to determine when an event meets specified criteria.

They are the reason most organizations need far fewer definitions than they expect. Rather than building a separate definition for each threshold or region, build one definition and gate its steps with conditions.

The four condition rule types

This table is close to guaranteed exam content, particularly the where allowed column.

Read validation conditions carefully - the logic is inverted relative to intuition. A validation condition that applies stops the process. You write the condition to describe the error state, not the acceptable state. "Effective date is before hire date" is a validation condition; "effective date is on or after hire date" is not.

Entry versus exit, in one sentence each

An entry condition asks should this step happen at all? An exit condition asks has this step done enough to stop? Approval chains are the only place both make sense, because a chain is a step that repeats.

While running versus exit on a chain

Both apply to chains and they answer different questions:

• While running - evaluated per link: does this particular person need to approve? If not, skip them and evaluate the next.
• Exit - evaluated for the chain: should the chain stop climbing now?

Workday's canonical exit condition is "approval from only two workers in the management chain."

Delivered conditions you cannot edit

Some business process steps have Workday-delivered entry conditions that you cannot edit. You can still configure additional entry conditions on those steps. The process evaluates both the Workday conditions and yours, skipping any step that does not satisfy all entry conditions.

That is an AND relationship, and it explains the frustrating case where a step is skipped although your condition is clearly satisfied - a delivered condition is not.

Building a condition rule

When you create a condition rule, it can include one or more and/or statements. These may be complex and can include parentheses to control the order of operations.

The fields you complete:

The Available Rules & Fields tab on the business process definition lists the condition rules and fields usable in conditional rule logic on that process. Check it before designing a rule: if the field you want is not there, the rule cannot reference it directly and you may need a calculated field.

Condition rules are effective-dated, like business process definitions and consolidated approvals. A future-dated rule change does not affect events already under way.

The two-step workflow

This is the mechanical trap from the previous section, restated because it belongs here:

1. Create Condition Rule - from the step's Related Actions. This creates the rule and saves it to a library. It does not add the condition to the step.
2. Maintain Step Conditions - from the step's Related Actions, in View mode. This is where you select and apply a condition rule to the step.

  Create Condition Rule  →  rule saved to the library
                             (step behavior unchanged)
                                      │
  Maintain Step Conditions ───────────┘
                             → rule applied to the step

Because rules live in a library, one rule can be applied to many steps across many definitions - which is efficient and also means an edit to a shared rule changes behavior everywhere it is used. Name rules for what they test, not for where you first used them.

Testing a condition rule

Conditions are logic, and logic needs both a positive and a negative case.

1. Prove the boundary in both directions. Run one test event that satisfies the rule and one that does not. A rule tested only on the satisfying case cannot distinguish "the condition works" from "the condition is ignored."
2. Test in a nonproduction tenant, using proxy to act as each assignee.
3. Watch for delivered conditions. If a step is skipped when you expected it to run, an uneditable Workday entry condition may be failing alongside your own.
4. Test the boundary values themselves, not only values well inside each side. Greater-than versus greater-than-or-equal-to is the most common defect in a threshold rule.
5. Confirm which version you exercised using View Definition for the date you are testing, since rules and definitions are both effective-dated.
6. Check the process history on the completed test event to see which steps ran, which were skipped, and why - covered in the next section.

Where condition rules go wrong in practice: the rule references a field whose value is not yet populated at the point the condition is evaluated. Entry conditions are evaluated when the process reaches the step, so a field set by a later step is empty. Ordering, not logic, is the fault.