11.2 Approvals & Approval Chains

11.2 Approvals & Approval Chains

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.

Almost every staffing story on the exam has an approval moment: Hire, Change Job, Terminate, Request Compensation Change, Create Position. Business Process Fundamentals (~10 of 50 questions) repeatedly tests whether you know 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:

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.

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.):

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:

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

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:

1. Map on paper: Initiate (HR Partner) → Propose Compensation subprocess → serial Manager approval → for leadership jobs, additional chain step to Regional Director → onboarding checklist.
2. Place Manager and HR Partner groups on Hire BP Security Policy with Initiate / Approve as designed.
3. Ensure Managers are role-assigned on each Store Team Supervisory Org (constrained).
4. Use condition rules (next chapter) so director-level job profiles take the longer chain while store associates take the short path.
5. 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. Exam items may tempt you to "fix missing approvers" with permanent unconstrained groups when temporary delegation is the operational answer.

Common Confusions Table

Study Focus for T48

1. Require approval using Approval and Approval Chain step types.
2. Contrast serial vs multi-approver / parallel patterns.
3. Tie who can approve to BP Security Policy + role routing + constraint.
4. Remember nested subprocesses may have their own approvals.
5. 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 on the 50-question exam.