12.1 Condition Rules

12.1 Condition Rules

Quick Summary: Condition rules attach logical true/false tests to business process steps so Workday can skip optional paths, enforce data quality, or stop chains when criteria are met. Create the rule, maintain it on the step, then test positive and negative cases with Rule Tester. On Workday Pro HCM Core, condition rules are a core Business Process Fundamentals skill (~20% of the 50-question, 80% pass, 100-minute exam).

Business Process Configuration at the step level starts with condition rules (task T49). Earlier chapters covered definitions, types, events, and step types (actions, approvals, subprocesses). This chapter assumes you can open a definition and now need the logic that makes one Hire path differ for executives, international locations, or high-risk changes without cloning an entire definition for every edge case.

Why Condition Rules Exist

A condition rule is a named set of logical statements connected to Workday data. At runtime, Workday evaluates those statements against the event (for example a Hire or Change Job in flight) and returns a true or false result that the step configuration interprets.

Without conditions, every step runs for every transaction of that definition. That produces noise (extra approvals no one needs), risk (missing a required review when risk is high), or sprawl (dozens of organization-specific definitions that differ by one if-statement). Conditions let a default definition stay maintainable while still encoding policy.

Configuration scenario: Contoso wants Manager approval on every Change Job, but an extra Compensation Partner review only when base pay increases more than 10%. The implementer keeps one Change Job definition, adds a review/approval step, and attaches an entry condition that is true only when the calculated pay-increase flag is true. Routine transfers skip the compensation step; large raises route it.

Four Condition Families (Exam Map)

Workday training groups conditions into four families. HCM Core exam language centers on entry and validation, but you must recognize the full set so distractors fail.

 Entry:     true  → include step
            false → skip step

 Validation: true  → block exit (data fails the check)
             false → allow exit (all validations must be false to proceed)

 While-running / Exit: specialized chain/integration control

Entry conditions (most common step filter)

Entry conditions determine whether a step needs to occur. If the condition applies, the step runs; if not, Workday skips the step and continues the definition. You can configure entry conditions on all step types except initiation. Some delivered steps ship with Workday-owned entry conditions you cannot edit; you can still add customer entry conditions. Workday evaluates delivered and customer entry conditions together and skips the step if not all entry conditions are satisfied.

Exam trap: Entry does not mean “user types a password.” Entry means “criteria to enter this step in the workflow.”

Validation conditions (data quality gate)

Validation conditions check the accuracy of data. Critical polarity for the exam:

• If any validation condition is true, the process will not continue (the step is blocked from exiting).
• If no validation conditions apply (all evaluate false), the step exits and the process continues.

Only Initiation and Action steps can carry validation conditions. Approvals are not the primary home for “require this field before submit”—that is validation on initiation/action (see also section 12.4).

Exam trap: “Validation true means good data.” False. For validation conditions, true = problem / block. All validation conditions must be false for clean exit.

While running and exit (chain-aware)

While running conditions exist only on Approval Chain and Consolidated Approval Chain steps. They decide whether the next user in the management chain still needs to approve; if not, Workday skips that user and evaluates further.

Exit conditions decide whether a chain or integration step should complete early. Available on approval chain variants and Integration steps. Classic pattern: approval chain continues until two managers have approved or until an exit condition is met.

Building a Condition Rule

Creating a condition rule is library work plus step attachment.

Create Condition Rule vs Maintain Step Conditions

From a step’s Related Actions (on the definition in View mode for many step features): Business Process → Maintain Step Conditions. From the definition, you can also create rules that save into the shared library.

Fields that shape rule logic

When you author a rule, you complete rows that combine into And/Or logic, optionally with parentheses for order of operations:

Rules can nest other condition rules as subrules. Prefer specific fields that narrow the population rather than vague “is not empty” checks that are always true or always false in practice.

True/false conditions and calculated fields (conceptual)

At a conceptual level for HCM Core:

1. Many rule rows are themselves true/false tests (field operator value).
2. You can back more complex logic with a True/False Condition calculated field that returns a Boolean based on boolean conditions, parentheses, and ordered tests.
3. That calculated field (or a condition rule wrapping it) becomes the source in a business process condition so the BP stays readable: “CF – Comp Increase Over 10% is equal to True.”

Calculated fields belong fully to the Report Writer track later; for BP configuration, remember the relationship: calculated true/false fields are a legal, high-value input to condition rules when delivered fields alone cannot express the policy.

 Calculated Field (True/False)
        │
        ▼
 Condition Rule (library)
        │
        ▼
 Maintain Step Conditions (entry or validation on a step)
        │
        ▼
 Runtime evaluation on the event

How Conditions Modify BP Behavior

Think of three modification patterns exam stems use:

1. Skip noise: Entry condition false → step skipped (no task in My Tasks).
2. Require extra path: Entry condition true only for high-risk cases → extra approval or To Do appears.
3. Hard stop for bad data: Validation condition true → user cannot complete initiation/action until data changes.

Configuration scenario: Global Retail’s Hire definition always runs Manager approval. An entry condition on an HR Partner review step is true when Country is not in the domestic list. Domestic hires skip the HR Partner step; international hires include it. Separately, a validation on the initiation step blocks submit when a required custom field “Export Control Cleared” is empty for certain job profiles.

Testing Condition Rules (T49 skill)

Creating a rule without testing is incomplete for both production and the exam’s “create and test” language.

Rule Tester

Troubleshoot with the Rule Tester task from a business process event that uses the rule: event Related Actions → Business Process → Test Rule. Access requires appropriate Business Process Administration domain security. The tester typically shows:

• Description of the condition rule
• Evaluation grid for each condition row (what was true/false)
• Whether other rules use it as a subrule
• Creation details
• Which business processes reference the rule

You can only open Rule Tester from events that actually use a condition rule—another reason sandbox end-to-end tests matter.

Test discipline

Always test the negative. If Management Level 3+ should enter an executive approval, Level 4 and below must skip. A rule that is always true looks “successful” on the first happy-path hire and then over-routes every transaction.

Exam scenario: “A condition always routes the step even for cases that should skip.” Diagnosis: rule always true; wrong comparison; wrong field timing; or entry conditions combined incorrectly with And/Or. Use Rule Tester on a concrete event rather than re-reading the label.

Available Rules & Fields Tab

On the business process definition, the Available Rules & Fields tab lists condition rules and fields you can use in conditional logic for that process. If a field is missing there, you cannot magic it into a step condition without a different approach (related business object, calculated field, or different process stage). This tab is the planning surface when designers ask “can Hire see proposed compensation before completion?”

Condition Rules vs Other Design Choices

Condition rules are not security groups. A step still needs a group allowed by the BP security policy. Conditions decide whether the step runs; security decides who is allowed to perform that step type when it does.

Common Confusions Table

Study Path Within Chapter 12

1. 12.1 (this section): Condition rule types, create/attach, true/false logic, test.
2. 12.2: Advanced routing, step label overrides, help text—who acts and what they see.
3. 12.3: Custom notifications triggered by BP events.
4. 12.4: Letter ordering to insert steps; validation conditions as definition-level data gates.

Memorize the entry vs validation polarity and the create vs maintain split before anything else. Those two distinctions convert most T49 stems into free points under exam timing (~2 minutes per item on a 50-question paper).