12.1 Condition Rules

Workday Pro HCM Core Certification Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Format 1.2 Eligibility, Learning Path & Access 1.3 Study Strategy & Blueprint Map

2 Navigation & Business Objects

2.1 Navigation Techniques in Workday 2.2 Business Objects & Finding Data

3 Organizations & Hierarchy

3.1 Organization Types & Subtypes 3.2 Supervisory Organizations & Reporting Structure 3.3 Cost Centers, Company Hierarchies & Locations 3.4 Leadership Roles & Worker Organization Assignments

4 Staffing Models

4.1 Position Management Staffing Model 4.2 Job Management Staffing Model 4.3 Hiring Restrictions on Organizations

5 Job Profiles & Job Structure

5.1 Creating & Editing Job Profiles 5.2 Job Profiles, Jobs, Positions & Workers 5.3 Job Families, Family Groups & Job Requisitions

6 Compensation Fundamentals

6.1 Compensation Framework Components 6.2 Eligibility Rules & Compensation Defaulting 6.3 Packages, Grades & Grade Profiles 6.4 Salary Plans, Allowance Plans & Worker Comp Events

7 Jobs, Positions & Staffing Events

7.1 Creating Positions & Position Hiring Restrictions 7.2 Managing Filled, Unfilled, Close & Freeze 7.3 Hire Process End-to-End 7.4 Job Changes & Additional Staffing

8 Termination & Contingent Workers

8.1 Terminate Employees 8.2 Contracting Contingent Workers 8.3 Ending Contingent Worker Contracts

9 Configurable Security

9.1 Functional Areas, Domains & Business Processes 9.2 User-Based, Role-Based & Workday-Assigned Groups 9.3 Domain Security Policies 9.4 BP Security Policies, Org Access & Activation

10 Business Process Framework

10.1 Organizations, Security & BP Relationships 10.2 Default, Org-Specific & Rule-Based Definitions 10.3 Definition, Type, Event & Step

11 Business Process Steps & Approvals

11.1 Actions & Subprocesses 11.2 Approvals & Approval Chains 11.3 Completing Tasks During Business Processes

12 Business Process Configuration

12.1 Condition Rules 12.2 Advanced Routing, Labels & Help Text 12.3 Custom Notifications 12.4 Step Ordering Letters & Validation Conditions

13 BP Management & Security

13.1 Mass and Individual BP Management 13.2 BPs and Configurable Security Interaction

14 Report Writer Fundamentals

14.1 Standard Reports & Copy/Modify 14.2 Building Custom Reports: Index vs Standard 14.3 Sorting, Filtering & Prompts 14.4 Report Security, Sharing & Ownership

15 Advanced Reporting & Calculated Fields

15.1 Scheduling Reports 15.2 Matrix Reports 15.3 Discovery Boards 15.4 Calculated Fields & Report Performance

12.1 Condition Rules

Key Takeaways Explain This Topic AI

Condition rules use logical field comparisons (And/Or, operators, comparison values) so a business process can skip, require, or block steps based on event data.

Entry conditions decide whether a step runs: if the rule evaluates true for the step design intent, the step executes; otherwise Workday skips it (not available as the sole control on initiation).

Validation conditions check data accuracy on Initiation and Action steps: if any validation condition is true, the step cannot exit and the process does not continue until the problem is fixed.

Create Condition Rule builds a reusable rule in the library; Maintain Step Conditions attaches a rule to a specific step—creating alone does not wire the step.

Test with Rule Tester from a real event (Related Actions → Business Process → Test Rule) and always verify both positive and negative scenarios, including calculated-field-backed true/false logic.

Last updated: September 2026

12.1 Condition Rules

Study index: T-numbers here refer to this guide’s index of an older Workday topic list. They are not current Workday task IDs or published exam weights.

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 (with no current public topic weight).

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.

Condition type What it answers If rule applies (true for the rule’s purpose) Typical steps

Entry Conditions Does this step need to run? Step runs (when configured as entry) Most step types except initiation

Validation Conditions Is data accurate enough to continue? Process is blocked until fixed; step does not exit cleanly Initiation and Action only

While Running Conditions Does the next person in a chain still need to act? May skip that user and evaluate the next Approval Chain / Consolidated Approval Chain

Exit Conditions Should this multi-hop step complete early? Step completes and process continues Approval chains and Integration steps 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

Task What it does What it does not do

Create Condition Rule Builds a reusable rule in the condition library Does not attach the rule to any step by itself

Maintain Step Conditions Selects and applies rules to a specific step (entry, validation, etc.) Does not invent fields; uses rules/fields available to the BP

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:

• Field Purpose Example
• And/Or Joins conditions And
• Source External Field or Condition Rule What you test (field or nested rule) Worker Location
• Relational Operator How you compare in the selection list
• Comparison Type Value you type vs another field Value specified in this filter
• Comparison Value Literal or comparison field Sweden

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:

Many rule rows are themselves true/false tests (field operator value).

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.

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

Distinguish three configuration patterns:

Skip noise: Entry condition false → step skipped (no task in My Tasks).

Require extra path: Entry condition true only for high-risk cases → extra approval or To Do appears.

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

• Practice Why
• Build and test one condition at a time Isolates which row flipped
• Test positive case (should enter / should block) Confirms intended path
• Test negative case (should skip / should allow) Catches always-true rules
• Use Business Object Details / data dictionary reports Find legal fields
• Use Report Fields and Values style checks See what is populated at event time
• Prefer narrow fields Avoid empty/is-not-empty traps

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

• Need Prefer
• One or two extra steps for special cases Entry conditions on a default definition
• Entirely different step sequences for one org Org-specific definition (inheritance)
• Different definition chosen at initiation by criteria Rule-based BP configuration (definition selection)
• Block bad data on submit Validation conditions on initiation/action
• Shorten management chain While-running / exit on approval chains

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

• Statement Verdict Why
• Create Condition Rule attaches the rule to the step Incorrect Maintain Step Conditions attaches
• Entry conditions apply to initiation Incorrect Entry excludes initiation; validation can sit on initiation
• Validation true means data is valid Incorrect True blocks ; all must be false to proceed
• While-running conditions work on simple Action steps Incorrect Approval chain variants
• Calculated true/false fields can feed conditions Correct Conceptual BP + CF link
• Always test only the happy path Incorrect Negative path is mandatory
• Study Path Within Chapter 12

12.1 (this section): Condition rule types, create/attach, true/false logic, test.

12.2: Advanced routing, step label overrides, help text—who acts and what they see.

12.3: Custom notifications triggered by BP events.

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 distinctions help you diagnose configuration behavior in the older-guide T49 topic.