8.2 Contracting Contingent Workers
Key Takeaways
- Worker has two primary subtypes on the exam: Employee and Contingent Worker—active/inactive and salaried/hourly are statuses or pay attributes, not subtypes.
- Contract Contingent Worker is the staffing event that brings a contingent worker into HCM; Hire is the parallel event for employees—do not use Hire for pure contractor onboarding.
- Contingent contracts capture engagement details such as contract dates, supplier/vendor context where used, job/profile and organization context, and other contract attributes required by the tenant design.
- Staffing model still applies: Position Management generally requires an open position (or valid seat path) before contracting into that seat; Job Management relies on org hiring restrictions without persistent vacant seats.
- Contingent workers can occupy positions, use job profiles, and sit in supervisory orgs—but they are not employees and follow contingent staffing events for start and end.
8.2 Contracting Contingent Workers
Quick Summary: Contingent Workers are non-employee workers tracked in Workday HCM. You bring them in with Contract Contingent Worker (not Hire), capture contract and job details, and staff them under the same Position Management or Job Management rules that govern the Supervisory Organization—without treating them as employees on payroll by default.
Blueprint task T35 Contracting contingent workers pairs with T34 (employee terminate) and T36 (end contingent contracts). Together they prove you can staff both Worker subtypes correctly. HCM Fundamentals is ~60% of the 50-question Workday Pro HCM Core exam; worker subtype mistakes are easy points lost if you collapse "everyone who works here" into a single Hire/Terminate story.
Worker Subtypes: Employee vs Contingent Worker
In Workday HCM fundamentals language, Worker is the parent business object. Two subtypes matter for staffing exams:
| Subtype | Who it is | Typical entry event | Typical exit event |
|---|---|---|---|
| Employee | Employed by the company | Hire | Terminate |
| Contingent Worker | Contractor, consultant, temporary non-employee engagement | Contract Contingent Worker | End Contingent Worker Contract |
Both subtypes can:
- Appear as workers with profiles and photos in search (subject to security).
- Belong to Supervisory Organizations for management hierarchy.
- Use Job Profiles to describe the work.
- Occupy Positions under Position Management.
They differ in employment relationship, default payroll treatment, benefits posture, and which staffing BPs create/end the relationship.
| Distractor | Why it is wrong on the exam |
|---|---|
| Active Worker vs Inactive Worker as "subtypes" | Active/inactive is status, not the Employee/Contingent subtype split |
| Salaried vs Hourly as subtypes | Compensation/pay attributes, not Worker subtype |
| Position Worker vs Job Worker | Staffing models, not Worker subtypes |
| "Contingent workers cannot use positions" | False—contingents can occupy positions when design allows |
What "Contracting" Means in Workday
Contract Contingent Worker is the staffing business process that creates (or reactivates, depending on history) a Contingent Worker relationship and places that worker into the organization/job (and position, when applicable) context for the engagement.
Think of it as Hire's sibling for non-employees:
Employee path: Hire → (work) → Terminate
Contingent path: Contract Contingent Worker → (engagement) → End Contingent Worker Contract
Contract details you should expect to reason about
Exact field labels vary by tenant and release wording; the exam cares about categories of data on the contingent engagement:
| Detail area | Examples of what is captured |
|---|---|
| Identity | Name, contact, pre-hire/candidate linkage as designed |
| Contract dates | Contract start; planned contract end |
| Work definition | Job Profile / job title context; location; time type as used |
| Organization | Supervisory Organization; other org assignments (Company, Cost Center, Region) |
| Seat (PM) | Which Position the contingent fills |
| Supplier / vendor context | Who supplies the worker when contingent supplier tracking is in use |
| Contract type / classification | How the engagement is categorized for reporting and policy |
Configuration scenario: Northwind engages a SAP cutover consultant for 6 months. HR runs Contract Contingent Worker into Sup Org "ERP Program – Delivery," Job Profile "Technical Consultant," Location HQ, contract start 1 June, contract end 30 November, supplier = Apex Consulting LLC. Under Position Management, they first ensured an open position "Cutover Consultant – Wave 2" existed with matching restrictions. The consultant is a Contingent Worker, not an Employee—no Hire event is used.
How Staffing Models Apply to Contingents
Staffing model is a property of the Supervisory Organization, not a separate "contingent-only model." T10–T14 still apply.
Position Management
- Capacity is seat-based.
- You typically Create Position (with position restrictions that allow contingent worker type if your design distinguishes worker types) before staffing the contingent into that seat.
- One primary occupancy per filled seat is the standard mental model.
- When the contract ends (T36), the Position remains and can be vacant for another contingent or employee backfill per policy—unless closed/frozen.
Job Management
- No persistent vacant seat inventory.
- Organization hiring restrictions constrain which profiles/locations/worker patterns can be contracted into the org.
- High-velocity contractor surges (seasonal warehouse support, short project waves) often fit Job Management stores/sites—if the business accepts weaker seat vacancy tracking.
| Question | Position Management answer | Job Management answer |
|---|---|---|
| Must a seat exist first? | Generally yes—open position path | No persistent seat required |
| Where are key limits? | Position restrictions (+ org design) | Org hiring restrictions |
| After contingent leaves, empty seat object? | Yes—position vacant | No durable empty seat |
| Can contingents use Job Profiles? | Yes | Yes |
Exam trap: "Contingent workers always use Job Management" is false. "Employees always use Position Management" is false. Model choice is org design, independent of subtype—though many tenants choose PM for specialized contractors and JM for high-volume temps.
Contract Contingent Worker vs Related Events
| Event | Creates new Worker? | Subtype / purpose |
|---|---|---|
| Hire | Yes (Employee) | Employee onboarding |
| Contract Contingent Worker | Contingent relationship (new or as designed for returning contractors) | Non-employee engagement |
| Add Job | No—adds another job to an existing Worker | Dual employment / additional job |
| Change Job | No | Move/change existing job context |
| Edit Position Restrictions | No | Change seat rules, not create a person |
Scenario trap: A manager says "just Hire the contractor so they show up in my org." If policy is contingent, the correct process is Contract Contingent Worker. Mis-hiring a contractor as an Employee creates wrong subtype, wrong payroll/benefits posture, and wrong exit process later.
Security and Process Awareness (Light Touch)
Who can initiate Contract Contingent Worker is controlled by Business Process Security Policy (who can initiate that BP type), often granted to HR Partners or contingent workforce coordinators on the relevant supervisory orgs. Domain security still controls what worker data is visible. For T35, remember:
- Initiation rights ≠ "anyone who can search for a Job Profile."
- Related Actions on a Position or Sup Org surface Contract Contingent Worker only when security allows.
- Approvals and To Dos can mirror Hire complexity (background check To Dos, supplier confirmation) depending on BP definition.
Design Patterns Worth Memorizing
- Project-based specialists — PM seats per project role; contract dates match project phase; end contract when phase ends; reuse or close seats.
- Staffing supplier pipelines — Contingent Worker + supplier attributes; reporting by supplier; still org/job structured.
- Hybrid orgs — Employees and contingents in the same Sup Org is possible when business design allows; do not assume contingents need a separate org type called "Contingent Hierarchy."
- Conversion foreshadow — Some contingents later become employees via a convert/hire path (exam depth in T36 as concept). Contracting correctly now avoids dirty data later.
Practical Mental Checklist (T35)
- Is the person a non-employee engagement? → Contingent path, not Hire.
- Collect contract dates, work definition, org, supplier context as required.
- Check staffing model: open position (PM) vs org restrictions (JM).
- Confirm Job Profile and restrictions allow the contingent combination.
- Plan the exit now: contract end date foreshadows End Contingent Worker Contract (next section)—not employee Terminate.
If you can explain why Contract Contingent Worker is Hire's sibling, list the main contract detail areas, and apply Position vs Job Management to a contractor scenario, you have T35 at Pro HCM Core depth.
What are the two primary Worker subtypes tested in Workday HCM Fundamentals?
Which staffing event is the correct entry path to bring a new non-employee contractor into Workday HCM as a Contingent Worker?
A Supervisory Organization uses Position Management. HR must staff a six-month technical contractor into a budgeted project seat. What staffing-model expectation is most accurate?
Which set of details is most characteristic of a Contract Contingent Worker engagement (as opposed to a pure employee Hire story)?