10.2 Default, Org-Specific & Rule-Based Definitions

10.2 Default, Org-Specific & Rule-Based Definitions

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.

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

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:

          ┌─────────────────────────┐
          │ 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

Design Guidance (Exam + Real Tenant)

1. Start from a solid default. Overrides should be explainable in one sentence.
2. Prefer rules when the driver is an attribute that spans many orgs (grade, worker type, country field).
3. Prefer org-specific when the driver is "this part of the tree always does X" without a clean shared attribute rule.
4. Document rule order the way you document security activation—silent reordering changes production behavior.
5. Test with representative initiations from each org and each rule population; do not assume the definition you edited is the one that fired.
6. 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)

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:

1. Rule-based (order 1): Management Level = Executive → steps include Compensation Committee + CHRO.
2. Rule-based (order 2): Company = Contoso Germany GmbH → steps include Works Council notification To Do.
3. Organization-specific: Supervisory org "Stores – West Region" → includes Regional HR approval.
4. Default: Manager approval + HR Partner approval.

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

Study Drill for T45

For any practice stem, force yourself to write:

1. What type is it?
2. What rule-based definitions exist and in what order?
3. Does any rule match the subject/transaction?
4. If not, is there an org-specific definition for the context org?
5. If not, default.
6. Separately: does security allow this initiator?

That six-line drill is enough to clear definition-selection items on the 10-question BP Fundamentals slice of the exam.