10.1 Organizations, Security & BP Relationships

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.1 Organizations, Security & BP Relationships

Key Takeaways Explain This Topic AI

Business processes, organizations, and security form one runtime triangle: the BP definition supplies steps, the organization supplies context and role holders, and security policies decide who may initiate and act.

Supervisory Organizations are the primary HCM context for staffing events such as Hire and Change Job; constrained role-based groups resolve against that org tree.

Who can initiate a business process is controlled by the Business Process Security Policy (Initiate) plus group membership and organization access—not by the definition alone.

A correct BP definition still fails at runtime if the initiator lacks Initiate permission, lacks domain access to required fields, or holds no role in the relevant org context.

Diagnose "I cannot start Hire" by separating layers: definition existence, BP security Initiate, domain View/Modify, role assignment, org access options, and policy activation.

Last updated: September 2026

10.1 Organizations, Security & BP Relationships

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: Workday business processes do not run in isolation. Organizations supply the context (especially Supervisory Orgs for HCM staffing). Security decides who may Initiate, Approve, View, and Rescind. Business process definitions decide which steps run. All three must align or the process will not start—or will start for the wrong people.

Business processes are one of the current published HCM Core concepts; Workday does not publish their current exam weight. Tasks T44–T46 establish the framework vocabulary and relationships before later chapters dig into steps, approvals, condition rules, and BP management. This section is the relationship map: how organizations, security, and business processes fit together at a high level.

Why the Triangle Matters

Every successful HCM workflow answers three questions at once:

What workflow runs? → Business process type and the definition selected for this initiation (default, org-specific, or rule-based—section 10.2).

In what organizational context? → Typically a Supervisory Organization (and related org assignments on the position) that supplies manager chains, role holders, and constrained security scope.

Who is allowed to participate? → Business Process Security Policies and Domain Security Policies listing security groups whose membership comes from roles on orgs, user lists, or Workday-Assigned criteria. Organizations

• (context & role holders)
• │
• ┌────────────┼────────────┐
• ▼ │ ▼
• Security groups │ Population scope
• (who is in bucket) │ (org access options)
• │ │ │
• └──────► BP + Domain policies ◄──┘
• │
• ▼
• Business Process
• (type → definition → event → steps)

If you only configure definitions and ignore security, nobody can initiate. If you only grant Initiate and ignore org context, constrained partners may open the wrong population—or no population. If you only assign roles and never attach groups to policies (or never activate policy edits), membership is ornamental.

Exam framing for T44: Stems that say "high-level relationships between organizations, security, and business processes" want this triangle—not a deep dive into approval-chain step types (later) and not a pure domain View/Modify definition question (Chapter 9).

• Organizations: Context for Process and People
• Supervisory Organizations as the HCM backbone

For most staffing business processes— Hire , Change Job , Terminate , Create Position , and related movements—the Supervisory Organization is the primary organizational context:

The position or job being staffed sits in a Supervisory Org.

The Manager role on that org is the default people leader for approvals and team visibility.

HR Partner , Compensation Partner , and other supporting roles are often assigned on supervisory nodes to cover a population.

Constrained role-based security groups resolve membership and scope from those role assignments and organization access options.

Non-supervisory orgs (Company, Cost Center, Region, Location, Custom) still matter for data defaults, eligibility, financial attribution, and some routing rules, but the exam's relationship story for "who acts on staffing events" almost always starts with the supervisory tree.

What "org context" means at initiation

When a user starts Hire for a position in Engineering → Platform Team :

• Context element How it influences the BP
• Supervisory Org of the position Anchors staffing; feeds constrained security and many default approval routes
• Manager on that org Common initiator or approver when security and definition route to Manager
• HR Partner on parent or node Often can initiate/approve for a broader span than a single team manager

Company / Cost Center / Location on position Affect defaults, validations, and sometimes condition rules—not usually "who is Manager"

Org-specific BP definition (if configured) May select a different step design for this org vs the default (section 10.2)

Configuration scenario: Contoso's Store Managers hold the Manager role on each Store Team supervisory org. They can initiate Hire only for their store because: (1) BP security grants Manager groups Initiate on Hire, (2) the groups are constrained , (3) organization access options limit them to their assigned org (and subordinates if designed), and (4) they only hold Manager on their store. Corporate HR Partners assigned on Region Leadership orgs cover many stores without being unconstrained enterprise-wide.

Security: Who Can Initiate and Act

Security is not a single switch. For business processes, separate what BP security does from what domain security does—Chapter 9 material that BP Fundamentals reuses constantly.

Business Process Security Policies

A Business Process Security Policy is maintained per business process type . It lists which security groups may perform workflow actions such as:

• BP action Meaning in relationship terms
• Initiate Start the process for an applicable target
• Approve Complete approval steps when routed to the group/role
• View See event information per policy design
• Rescind Rescind an eligible completed (or otherwise rescindable) event

Who can initiate is therefore:

A person in a security group that is granted Initiate on that BP type's security policy, and

That membership is meaningful in the organization context (for constrained role-based designs: role assigned on the right org + org access options), and

Any pending policy edits were activated if the policy was recently changed, and

Domain security allows them to open the tasks and fields the initiation requires.

Exam trap: "Who can initiate" is not answered by "whoever is listed as a step in the definition." Definitions describe steps; security policies authorize participation. A definition may include Manager Approval, but if the Manager group lacks Approve on the BP policy, the step cannot be completed correctly.

Domain security still participates

Even with perfect Initiate rights, a user who cannot View/Modify required worker, job, or compensation domains will stall mid-process. Integrations need Get/Put . The relationship model is:

• Need Layer
• Start the workflow BP security: Initiate
• Act on approval / To Do / action steps BP security for the action + definition routing to the right role/group
• Edit/see data on steps Domain security: View/Modify (Get/Put for integrations)
• Limit population Constrained groups + org access options + role assignment
• Business Processes: What Runs

A business process in framework language is the combination of:

• a type (Hire Employee, Change Job, …),
• one or more definitions (the configured step lists),
• runtime events (instances), and

steps inside each running event.

Those terms are defined in full in section 10.3. For relationships, remember only this: definitions shape the path ; they do not replace security or invent org membership. Type: Hire Employee

• └── Definition selected (default / org-specific / rule-based)
• └── Event: Hire of Alex Rivera into Platform Team
• └── Steps: Propose Hire → HR Review → Manager Approve → …

Organization context influences which definition may be selected (org-specific and rule-based designs) and which people security resolves as participants. Security influences whether those people may perform the step actions the definition expects.

High-Level Relationship Statements (Memorize These)

Use these as quotable exam answers:

Organizations provide context for staffing processes and for role-based security membership and population scope.

Security policies grant permissions to security groups; groups do not grant access by themselves.

BP security controls workflow participation (Initiate, Approve, View, Rescind); domain security controls data/task access.

BP definitions control which steps run and in what order; they assume security and org design will supply real participants.

Initiation requires BP Initiate permission in the correct org context—not merely knowing the Hire task name.

Relationship Table for Exam Scenarios

Symptom Org layer? Security layer? BP definition layer?

User cannot find or start Hire Maybe wrong org / no target position Missing Initiate; group not on policy; not activated Type/definition exists but irrelevant if security blocks

Manager can hire only own team Expected constrained org scope Constrained Manager group + org access N/A if initiation works

HR Partner of Engineering sees Finance Role on wrong org or unconstrained / org options too wide Scope misconfiguration Definition not the cause

Hire starts but approval never reaches manager Manager role missing on Sup Org Approve missing for Manager group Step may route to Manager but empty inbox if no role

Hire starts with wrong extra approval steps Org-specific or rule-based definition selected Usually not Definition selection / configuration

• User initiates but cannot edit job fields Org OK Domain View/Modify missing Step exists; data access fails
• Worked Scenario Bank (T44 Style)
• Scenario A — Triangle success

Northwind assigns Manager on Assembly Line 1, uses a constrained Manager security group on Hire Initiate and Approve, activates policies, and uses the default Hire definition with a Manager Approval step. Result: the Assembly Line 1 manager can initiate and approve Hire for that org's positions. All three layers cooperate.

Scenario B — Security missing

Same org design, perfect Hire definition, but Manager group was never added to Hire Initiate . Result: managers cannot start Hire. Definition and org are fine; BP security is not.

Scenario C — Org context missing

HR Partner group has Initiate on Hire and is constrained, but nobody assigned HR Partner on the new "Cloud Services" supervisory org after a reorg. Result: partners who should cover Cloud Services cannot act for that population. Policy exists; org role assignment does not.

Scenario D — Domain gap

User can initiate Change Job (BP Initiate OK) but cannot open compensation fields on a step. Result: domain security (or related field security) is incomplete. BP relationship includes domains, not only BP policies.

Scenario E — Activation gap

Admin adds HR Partner to Hire Initiate today and forgets Activate Pending Security Policy Changes . Result: runtime still follows the last activated policy—partners still blocked. Pending policy edits are not live.

Who Can Initiate: Decision Checklist

When diagnosing who can initiate a business process based on security and org context, walk this checklist:

Identify the business process type (Hire, Change Job, Terminate, …).

Confirm a definition will be selected (default at minimum—details in 10.2).

Identify which security groups have Initiate on that type's BP security policy.

Determine how membership works for those groups (role-based constrained, unconstrained, user-based, Workday-Assigned).

For constrained role-based groups, verify role assignment on the relevant organization and organization access options .

Confirm domain access needed to complete initiation screens.

Confirm activation if policies were recently edited.

The person who "should" initiate from a process-design perspective is not always the person who can initiate. Design intent lives in definitions and operating procedures; can is a security + org fact.

Common Confusions Table

• Statement Verdict Why
• BP definition alone determines who can initiate Incorrect BP security Initiate + membership/org context
• Organizations are only for cost allocation Incorrect Sup Orgs drive staffing BP context and role scope
• Domain View equals BP Initiate Incorrect Different policy objects and purposes

Manager role assignment without policy membership is enough Incorrect Group must be on BP (and domain) policies

• Constrained access ignores supervisory hierarchy Incorrect Constrained designs resolve against org context
• Security, orgs, and BPs are independent silos Incorrect Runtime requires all three
• How This Section Connects Forward

Next topic Why it depends on T44

10.2 Definitions Org-specific and rule-based definitions select step designs within org/rule context; security still gates participation

• 10.3 Terminology Type/definition/event/step language describes the BP side of the triangle
• BP steps & approvals Routing assumes roles and security groups exist in org context
• BP security interaction Deepens how configurable security and BP configuration partner

Master the triangle before memorizing step letters. Under ~2 minutes per question, T44 items reward instant separation of context (org) , permission (security) , and workflow design (BP) .