11.1 Actions & Subprocesses

11.1 Actions & Subprocesses

Quick Summary: Business Process steps are the building blocks of every HCM event. An Action is a user-performed task on the parent (or nested) process. A Subprocess launches another full Business Process inside the parent—most famously Propose Compensation from Hire. To Do and Checklist sit nearby in the step family as instructional and grouped-task patterns. Knowing which step type does what is core to task T47 and to finishing work in My Tasks.

Business Process Fundamentals is about 20% of Workday Pro HCM Core (10 related questions of 50, 80% pass, 100 minutes). After the framework chapter (definitions, types, events, steps at a high level), this chapter zooms into how work gets done: action steps, nested processes, and the neighboring step types you will see on almost every Hire, Change Job, and Termination design.

Why Step Types Matter

A Business Process definition is an ordered (and sometimes branched) set of steps. Each step has a type that decides:

1. What kind of work appears (data entry, approval, reminder, nested workflow),
2. Who can act (via BP Security Policy permissions and routing),
3. Whether the parent process waits on that step before continuing,
4. How completion is recorded in Worker History / process history.

If you mislabel a step type on the exam, you will pick the wrong security surface, the wrong completion behavior, or the wrong fix when a Hire is stuck.

Valid Step Types (Exam Catalog)

Exam trap: Connector (Core Connector / integration pattern) is not a Business Process step type. If a stem lists Action, Approval, To Do, and Connector and asks which is not valid, answer Connector.

 Parent BP (e.g., Hire Employee)
   ├── Action steps (initiation data, other tasks)
   ├── Approval / Approval Chain steps
   ├── To Do / Checklist steps
   ├── Subprocess ──► Child BP (e.g., Propose Compensation Hire)
   │                      ├── its own Action / Approval / To Do steps
   │                      └── its own BP Security Policy
   └── Service steps (as configured)

Action Steps: Completing Real Work

An Action step is the workhorse step type for doing something in the event—not merely saying "yes/no" to someone else's proposal.

What an Action represents

• A task assigned to a security group / role routing design so a person opens My Tasks and performs it.
• Often includes data entry or confirmation on the event (job details, personal data collection tasks, compensation-related actions when modeled as actions rather than only as nested BPs).
• Moves the BP forward when the assigned actor submits/completes the action successfully.

Action vs Approval (clean split)

Configuration scenario: On Contoso's Hire definition, after the initiator submits Hire, an Action routes to HR Partner to complete remaining hire details before Manager Approval. The HR Partner is not "approving" in the approval-step sense; they are acting on a task. Confusing Action with Approval is a common vocabulary miss.

Completing Actions during BPs

From the runtime user's perspective (preview of section 11.3):

1. Open My Tasks (Inbox).
2. Open the Action item for the event.
3. Complete required fields / instructions.
4. Submit so the step completes and the definition advances.

If the user lacks security to perform that action for that BP, the item will not appear for them (or they cannot complete it)—fixing is as much a security diagnosis as a step-type diagnosis.

Subprocess Steps: Nested Business Processes

A Subprocess step invokes another Business Process from inside a parent process. The nested BP is a first-class process: it has a type, a definition (default / org-specific / rule-based as designed), steps, conditions, and a Business Process Security Policy of its own.

Classic HCM example: Propose Compensation from Hire

On many Hire designs:

1. Initiator starts Hire Employee (parent).
2. A Subprocess step starts Propose Compensation Hire (or the tenant's compensation propose process for hire).
3. The compensation process collects pay plan amounts, grades, allowances as configured.
4. Approvals inside the compensation subprocess may fire per that definition.
5. When the subprocess completes successfully, the parent Hire can continue to later steps (additional To Dos, service dates, onboarding, etc.).

Similar nesting appears on Change Job (propose compensation change), Add Job, and other staffing movements where pay must be proposed as a reusable workflow rather than a one-off field on the parent only.

Why subprocesses exist (design value)

Exam scenario: "Hire includes a Subprocess to Propose Compensation. Who controls who can complete the compensation proposal?" → The Propose Compensation BP Security Policy (subprocess policy), not only the parent Hire policy. Both must be correct for end-to-end success.

Subprocess vs Action (exam trap)

To Do and Checklist: Step-Family Neighbors

Blueprint T47 centers on Actions and Subprocesses, but exams freely mix neighboring types. Treat To Do and Checklist as family members you must differentiate.

To Do

A To Do is a single instructional or reminder step. Examples:

• "Schedule welcome meeting"
• "Collect equipment"
• "Complete exit interview notes"

To Dos can be configured as required (blocking) or not required (informational / parallel awareness depending on design). Do not memorize a universal rule that "To Dos never block"—the bank and training emphasize that either To Do or Checklist can be blocking or non-blocking per configuration.

Checklist

A Checklist is a collection of related to-dos grouped into one step. Ideal for:

• Onboarding packs (I-9 related tasks, policy acknowledgments as designed, IT setup list),
• Offboarding packs (return badge, revoke access, knowledge transfer),
• Compliance bundles that should travel together.

Exam trap: "Checklists always block; To Dos never block" is too absolute. "There is no difference" is also wrong. The durable distinction is single item vs curated collection.

Onboarding and offboarding narrative

Onboarding work often hangs off Hire as subprocesses, To Dos, and Checklists (personal information, government IDs, setup tasks) landing in the new hire's or HR's My Tasks. Offboarding hangs similarly off Termination. You do not need tenant-specific checklist names; you need the pattern: step types implement operational consistency.

How Actions and Subprocesses Fit the Parent Flow

 Initiate Hire
      │
      ▼
 [Action / data steps as designed]
      │
      ▼
 Subprocess: Propose Compensation Hire  ──► complete nested steps / approvals
      │
      ▼
 Approvals on parent (if any remain)
      │
      ▼
 To Dos / Checklists (onboarding)
      │
      ▼
 Event Completes → Worker History shows parent + nested activity

Security and completion checklist for stuck Hires

When a Hire is stuck after initiation:

1. Identify the current step type (Action vs Approval vs Subprocess child step).
2. Confirm the assignee security group can act on that BP policy.
3. If the step is inside a subprocess, open the child event and its security—not only the parent.
4. Confirm the step is not waiting on a parallel sibling (section 11.3).
5. Confirm the definition in force is the expected default / org-specific / rule-based definition (framework chapter).

Configuration Scenario (End-to-End Teaching Story)

Northwind redesigns Hire for engineers:

1. HR Partner Initiates Hire (BP Security: Initiate).
2. Action step: Recruiter completes remaining hire attributes if initiation was partial.
3. Subprocess: Propose Compensation Hire routes to Compensation Partner; amounts validated against grade; Compensation Partner submits; optional compensation approvals fire on the compensation definition.
4. Approval: Manager of the supervisory org approves the hire package.
5. Checklist: Onboarding pack (equipment, accounts, welcome) assigned to Manager and IT roles as designed.
6. Event completes; Worker History shows the hire and nested compensation activity.

If Compensation Partner cannot act, fix Propose Compensation security—not by adding them only to an unrelated domain without BP rights, and not by converting the subprocess into a Connector step (invalid type).

Study Focus for T47

1. Define Action as performable task work on a BP.
2. Define Subprocess as nested BP (Propose Compensation from Hire is the poster child).
3. Separate parent vs child security policies.
4. Differentiate To Do vs Checklist as single vs collection.
5. Reject Connector as a BP step type.

Master these five, and most Action/Subprocess items on the 50-question exam become free points under the ~2-minute-per-item pace.