11.2 Approvals & Approval Chains

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

11.2 Approvals & Approval Chains

Key Takeaways Explain This Topic AI

Approval steps require one or more designated actors to approve (or deny/send back) before the Business Process can continue past that control point.

An Approval step is the single-approval-step pattern; an Approval Chain is the multi-level or multi-person chain pattern used when more than a simple one-stop approval is required.

Serial approval patterns require ordered completion (A then B); multi-approver and parallel patterns can require several people, sometimes concurrently, before the join advances.

Who can approve is governed by Business Process Security Policy (Approve permission) plus routing design (roles, security groups, advanced routing)—not by domain Get/Put alone.

Skipping approvals to 'speed up' a design removes the control purpose of the BP; map serial vs multi-approver needs on paper before configuring in a tenant.

Last updated: September 2026

11.2 Approvals & Approval Chains

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: Approvals are the control points of HCM workflows. An Approval step routes review to authorized actors; an Approval Chain supports multi-level or multi-person approval patterns. Who can approve is a Business Process Security Policy question (Approve permission) combined with routing to the right role or group. Task T48 expects you to require approval correctly—not just to recognize the word "approve" on a screen.

Many staffing workflows include an approval moment: Hire, Change Job, Terminate, Request Compensation Change, Create Position. Business process practice should cover how approvals are modeled and who is allowed to complete them.

Why Approvals Exist

A Business Process without controls is just a data entry form. Approvals enforce:

Separation of duties (initiator is not always the final approver),
Manager accountability for team changes,
HR / Compensation oversight for compliance and pay equity,

Auditability (Worker History shows who approved and when).

Exam trap: "Skip approvals to speed production" is never the professional first design step. Best practice is to map steps, conditions, security groups, and serial/parallel needs before configuring—then test in implementation/sandbox.

Approval vs Approval Chain

Both appear in the valid step-type catalog. Use this conceptual split for the exam:

Concept What it models Mental model

Approval An approval step in the definition—typically the simple one-stop (or discrete) approval step pattern "This step must be approved by the configured approver set"

Approval Chain A chain pattern for multi-level or multi-person approval sequencing as designed "Approval walks a chain (for example Manager → Director → HR)"

You do not need to invent every tenant's chain UI labels. You do need to know that Workday distinguishes Approval and Approval Chain as step types, that chains exist for richer multi-approver designs, and that both still depend on who has Approve on the BP security policy and how routing resolves people. Simple Approval step

Initiator → [Approval: Manager] → complete / next steps

Approval Chain (illustrative)
Initiator → [Chain: Manager → Director → Comp Partner] → next steps
Serial vs Multi-Approver Patterns
Serial approvals

In a serial pattern, approvals (or steps) complete in order . B does not become the active approval work until A finishes (unless a parallel design says otherwise).

Example: Manager must approve Change Job before HR Partner's approval step becomes due.

Multi-approver patterns

Multi-approver designs require more than one person (or role instance) to approve. That may be:

Multiple steps in series (Manager, then Director),
Multiple approvers at a chain level,

Parallel approval steps that fire together and join when all required approvers finish.

Parallel approvals (link to runtime awareness)

When two BP steps are parallel , they become available at the same logical time , and the process typically waits for all required parallel steps before continuing past the join. Example: HR Partner and Manager approve concurrently rather than waiting on each other in sequence.

Pattern Behavior Exam phrase to watch
Serial Ordered; later waits on earlier "must approve before"
Parallel multi-approver Concurrent; join waits for all required "at the same time" / "both must complete"
Single Approval step One approval control point as configured "Manager approval only"
Approval Chain Multi-level chain pattern "chain of command" / multi-level

Exam scenario A: "HR Partner and Manager must both approve Hire, and the design fires both approval tasks together." → Parallel multi-approver pattern; process waits for both.

Exam scenario B: "Director only sees the approval after Manager approves." → Serial pattern.

Who Can Approve: Security Ties

Approvals are useless if the wrong people (or no people) can act. Approval authority is not "anyone who can View the worker."

BP Security Policy: Approve

On the Business Process Security Policy for that process type (Hire, Change Job, etc.):

Permission (workflow) Meaning
Initiate Start the BP
Approve Act on approval steps / chains as policy allows
View (event) See the event
Rescind Reverse completed events when allowed
Other actions As listed on the policy for that BP

Domain permissions (View/Modify/Get/Put) still matter for seeing data fields, but Approve is a BP permission. Section 9.x of this guide covered that split; T48 assumes you apply it to approvals.

Routing to real people

Security policy answers which groups may approve . Routing answers which person instance gets the My Tasks item:

Manager of the subject's Supervisory Organization,
HR Partner assigned on the org,
Compensation Partner for pay events,
Other role-based or specified security groups per design,

Advanced routing (later configuration chapter) for exception paths.

Constrained role context

For role-based groups that are constrained , the approver's authority is limited to their organization context . Manager of Engineering does not become universal Hire approver for Finance merely because Approve is on the Manager group—the routing + constraint keep the item on the correct manager. BP Security Policy: Approve → Role-based group "Manager" (constrained)

+
Routing: Manager of subject's Supervisory Org
=
My Tasks item for that specific Manager

Exam trap: "Unconstrained means the user has no approve rights." False —unconstrained is broader org scope, not zero permission.

Approval Outcomes and Process Progress

While exact button labels can vary by tenant/UI generation, conceptual outcomes you must reason about:

Outcome Effect on the event
Approve Step completes; process advances (or continues the chain)

Deny / Reject (as configured) Stops or fails the path per definition—event does not happily complete as approved

Send Back (as configured) Returns work to a prior participant to revise

Approvals are control points , not decorations. A Hire sitting in Manager approval is in progress ; Cancel may still be available to permitted users until the overall event successfully completes (section 11.3).

Approvals Across Common HCM Processes

Business Process Typical approval intent
Create Position Finance / leadership control before capacity exists (especially Position Management)
Hire Manager/HR confirm the hire package; compensation may have nested approvals
Change Job Manager/HR confirm transfer, promotion, demotion, lateral
Request / Propose Compensation Pay governance, grade range control
Terminate Manager/HR confirm exit

Nested Propose Compensation may carry its own approvals under the subprocess definition while the parent also has approvals—diagnose which event is waiting.

Configuration Scenario

Global Retail Co. wants store-level hires approved quickly but multi-level for director-level jobs:

Map on paper: Initiate (HR Partner) → Propose Compensation subprocess → serial Manager approval → for leadership jobs, additional chain step to Regional Director → onboarding checklist.

Place Manager and HR Partner groups on Hire BP Security Policy with Initiate / Approve as designed.

Ensure Managers are role-assigned on each Store Team Supervisory Org ( constrained ).

Use condition rules (next chapter) so director-level job profiles take the longer chain while store associates take the short path.

Test with a store Manager account and a Regional Director account; confirm My Tasks routing and that Finance is not accidentally unconstrained enterprise approver.

Delegation (Nearby Concept)

Delegation temporarily assigns your BP step responsibilities (including approvals) to another user—commonly during PTO. It is not permanent role reassignment (that is Assign Roles). Delegation is security-governed and can scope which processes and which date range. For a temporary absence, consider delegation before changing permanent role assignments or granting unconstrained access.

Common Confusions Table

Statement Verdict Why
Approve is a Domain permission like Put Incorrect Approve is BP Security Policy
Approval Chain is the same as Connector Incorrect Chain is a BP step type; Connector is not
Parallel means different servers Incorrect Logical concurrency of steps
Serial means random order Incorrect Ordered completion
Anyone who can View worker can Approve Incorrect Need Approve + routing
Map workflow before configuring Correct BP design best practice
Study Focus for T48

Require approval using Approval and Approval Chain step types.

Contrast serial vs multi-approver / parallel patterns.

Tie who can approve to BP Security Policy + role routing + constraint.

Remember nested subprocesses may have their own approvals.

Prefer design mapping over skipping controls.

If T47 is "what work runs," T48 is "who must say yes before it counts." Together they are the operational heart of Business Process Fundamentals in HCM Core study.