10.2 Default, Org-Specific & Rule-Based Definitions

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

10.2 Default, Org-Specific & Rule-Based Definitions

Key Takeaways Explain This Topic AI

Each business process type can have multiple definitions; exactly one definition is selected when an event is initiated.

The default definition is the baseline configuration used when no more specific definition applies.

Organization-specific definitions apply when the process is initiated in the context of a designated organization (and configured applicability).

Rule-based definitions apply when their condition rules evaluate true; rules are evaluated in order so the first matching rule-based definition wins.

Mental model for selection: evaluate rule-based definitions in order → else organization-specific match → else default.

Last updated: September 2026

10.2 Default, Org-Specific & Rule-Based Definitions

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: A business process type can have several definitions . Workday selects one definition when someone initiates an event. Rule-based definitions win when their condition is true (first match in order). Else an organization-specific definition may apply for the initiating org context. Else the default definition runs. Think override hierarchy, not three processes running at once.

Task T45 is pure framework skill: given a tenant design, which definition fires? Implementers use multiple definitions so Europe can require extra compliance steps, executives can route through additional approvers, or union populations can follow a different path—without cloning an entire product.

Definitions Live Under a Type

Recall the stack (detail in 10.3):

Business Process Type — delivered kind of process (Hire Employee, Change Job, Terminate Employee, …).

Business Process Definition — a configured ordered set of steps for that type.

Event — one running instance for a subject (for example, Hire of a named worker).

You do not create a new type for "Hire – Europe." You create another definition under the Hire type and control when it is selected.

• Definition kind When it is intended to run Configuration idea
• Default When nothing more specific applies Baseline enterprise process

Organization-specific When initiation context matches a designated org (per config) Local legal, HR, or operational path

Rule-based When a condition rule evaluates true for the transaction Attribute-driven path (comp grade, worker type, location, custom fields, etc.)

Exam trap: Default does not mean "broken" or "temporary." It means baseline . Many tenants run almost everything on a well-designed default and add only a few overrides.

Default Business Process Definitions

The default definition is the definition Workday uses for a type when no rule-based definition matches and no applicable organization-specific definition is selected. It is the safety net and the standard path.

Characteristics

There is a clear default definition for the type (customers maintain it; Workday delivers starting points that tenants copy/customize per methodology).

It should be complete enough to run the process for the general population.

Overrides (org-specific and rule-based) should be exceptions with clear business reasons , not an ungoverned forest of near-duplicates.

Configuration scenario: Global Retail's default Hire definition includes HR initiate/review, Manager approval, and standard onboarding To Dos. That path covers the majority of store and corporate hires. Only special populations get other definitions.

Organization-Specific Definitions

An organization-specific definition is tied to a particular organization context—commonly a Supervisory Organization or another org used as the BP's organizational basis—so that initiations in that context use a different step design than the default.

Why implementers use them

Business need Why org-specific fits

Country or division compliance steps Legal entity or regional supervisory subtree needs extra approvals or To Dos

• Centralized vs local HR models Corporate orgs route to shared services; plant orgs route to plant HR
• Pilot programs One org runs a new hire checklist before enterprise rollout
• Union or site practices A site supervisory org always needs an extra notification or review
• Mental model Hire Employee (type)
• ├── Default definition ────────────────── general population
• ├── Org-specific: EMEA Leadership ─────── EMEA context hires
• └── Org-specific: Plant A ─────────────── Plant A context hires

When a hire is initiated in Plant A context and no rule-based definition matches first, Workday can select the Plant A organization-specific definition instead of default. A hire in an org without its own definition falls through to default (unless a rule-based definition matched).

Exam trap: Organization-specific is not the same as constrained security. Constrained security limits who can see/act on which people . Org-specific definitions change which steps run for initiations in that org context. You often need both : Plant A managers are constrained to Plant A and Plant A may use a different Hire definition.

Configuration scenario: Contoso creates an organization-specific Change Job definition for the "Executive Team" supervisory org that inserts an additional Compensation Committee approval step. Non-executive orgs keep the default Change Job definition with Manager + HR Partner only.

Rule-Based Definitions

A rule-based definition is selected when its associated condition rule evaluates to true for the transaction at definition-selection time. Rules let you key off attributes that are not simply "this one org node"—for example:

• Worker type or contingent vs employee
• Job family, management level, or compensation grade
• Location or region attributes
• Custom fields or calculated conditions used in BP rules
• Combinations (AND/OR) expressed in the condition rule
• Order matters

Rule-based definitions are evaluated in a defined order . The first rule-based definition whose condition is true is selected. Later rule-based definitions are not used for that event even if their rules would also have been true. Evaluate rule-based definitions in order:

• 1. Rule: Is Executive Management Level? → Executive Hire definition
• 2. Rule: Is Location Country = DE? → Germany Hire definition
• 3. Rule: Is Contingent Worker hire path? → Contingent Hire definition
• If none true → consider org-specific → else default

Exam trap: "All matching rule-based definitions merge their steps." → False. One definition is selected. First matching rule-based definition wins, then other selection logic applies only if no rule matched.

Configuration scenario: Northwind wants any hire into compensation grade profile "Exec" to use a definition with CEO approval, regardless of which supervisory org initiates. A rule-based definition with a condition on grade/profile is a better fit than cloning org-specific definitions on every executive org.

Which Definition Fires? Inheritance / Override Mental Model

Treat definition selection as an override stack from most specific conditional design to baseline:

Priority (conceptual) Definition kind Question Workday is answering

1 (first match wins) Rule-based (in listed order) Does a condition rule say "use this path"?

2 Organization-specific Is there a definition for this org context?

• 3 Default Use the baseline path ┌─────────────────────────┐
• │ Rule-based (ordered) │ ← first true rule wins
• └───────────┬─────────────┘
• │ none matched
• ▼
• ┌─────────────────────────┐
• │ Organization-specific │ ← org context match
• └───────────┬─────────────┘
• │ none
• ▼
• ┌─────────────────────────┐
• │ Default definition │ ← always available baseline
• └─────────────────────────┘
• Worked selection examples
• Example 1 — Default only

Tenant has only a default Hire definition. Any initiate → default .

Example 2 — Org-specific override

Default Hire + org-specific Hire for "Germany HR Org." Initiate in Germany HR Org context, no rule-based definitions → Germany org-specific . Initiate in France → default .

Example 3 — Rule beats org-specific

Rule-based "Executive" Hire is first in order. Org-specific Hire exists for Plant A. An executive-level hire initiated in Plant A matches the executive rule → rule-based Executive definition , not Plant A's org-specific definition.

Example 4 — Rule order tie-break

Rule 1: Country = DE → Germany definition. Rule 2: Grade = Exec → Executive definition. A German executive hire matches Rule 1 first → Germany definition , even though Rule 2 would also be true. Designers who wanted executives everywhere on the executive path must order the executive rule above the country rule or combine conditions carefully.

Example 5 — Security is independent

Plant A org-specific Hire is selected, but the initiator lacks Initiate on Hire BP security. No event runs —definition selection never rescues missing security. Selection assumes a successful initiate by an authorized user.

Comparing the Three Side by Side

• Dimension Default Organization-specific Rule-based
• Trigger Fallback Org context of initiation Condition rule true
• Specificity Lowest Medium (org-scoped) Highest when ordered first and conditions fit
• Best for Enterprise baseline Local org practices Cross-org attribute logic
• Order sensitivity N/A Among org defs by context match Critical among rule-based defs
• Multiple can exist One default role Many (different orgs) Many (different rules)
• Selected count per event At most one definition total per initiation At most one At most one
• Design Guidance (Exam + Real Tenant)

Start from a solid default. Overrides should be explainable in one sentence.

Prefer rules when the driver is an attribute that spans many orgs (grade, worker type, country field).

Prefer org-specific when the driver is "this part of the tree always does X" without a clean shared attribute rule.

Document rule order the way you document security activation—silent reordering changes production behavior.

Test with representative initiations from each org and each rule population; do not assume the definition you edited is the one that fired.

Do not confuse definition selection with step condition rules inside a single definition (those skip or include steps after a definition is chosen—later configuration chapters). T45 is about which definition , not which step inside it.

Definition selection vs step conditions (preview)

• Mechanism Selects Layer
• Rule-based / org-specific / default Entire definition (whole step list) Definition-level (T45)
• Condition rules on steps Whether a step applies inside the chosen definition Step-level (later BP config)

Exam trap: A stem about "which Hire definition runs for executives" is T45 definition selection . A stem about "skip the bonus step when allowance is zero" is step condition configuration, not choosing default vs org-specific.

• Realistic Multi-Definition Case Study
• Tenant: Contoso global HCM
• Type: Change Job

Definitions:

Rule-based (order 1): Management Level = Executive → steps include Compensation Committee + CHRO.

Rule-based (order 2): Company = Contoso Germany GmbH → steps include Works Council notification To Do.

Organization-specific: Supervisory org "Stores – West Region" → includes Regional HR approval.

Default: Manager approval + HR Partner approval.

• Initiation Matching logic Definition used
• Store associate, US, non-exec, East Region No rules; no West org-specific Default
• Store associate, West Region, non-exec No rules; West org-specific matches West Region org-specific
• German non-exec professional Rule 2 true Germany rule-based
• German executive Rule 1 true first Executive rule-based (Germany rule never reached)
• US executive in West Region Rule 1 true first Executive rule-based (West org-specific not used)

Security still decides who may initiate each of those Change Job events; the table only answers which path runs after a valid initiate.

Common Confusions Table

• Statement Verdict Why
• Three definitions can merge into one event Incorrect One definition per initiation
• Default means temporary draft only Incorrect Default is the baseline production path
• Org-specific replaces constrained security Incorrect Different problems: path vs population permission
• Rule order is irrelevant Incorrect First true rule-based definition wins
• Rule-based always loses to org-specific Incorrect Rule-based is evaluated first in the standard mental model
• Missing Initiate is fixed by adding a default definition Incorrect Security vs definition layers
• Study Drill for T45

For any practice stem, force yourself to write:

What type is it?

What rule-based definitions exist and in what order ?

Does any rule match the subject/transaction?

If not, is there an org-specific definition for the context org?

If not, default .

Separately: does security allow this initiator?

Use this six-line drill for business-process definition-selection practice.