Workday // contingent workforce

Your agencies submit. Workday gets three real transactions.

Your staffing agencies never get a Workday account. The agency fills in one guided form, and WorkerIn submits three Workday web service operations in sequence, each one firing only if the previous returned an ID, through a single integration system user you create, scope and can switch off. Your own onboarding path stays exactly as it is.

Put_Applicant / Recruiting Create_Position / Staffing Contract_Contingent_Worker / Staffing

Request a walkthrough Vendor sign-in

Built by a Principal Workday Consultant with 25 years in the field. The walkthrough runs against a demo tenant with sample data, and the three transactions really fire.

Submitted to Workday

Applicant ID 184898Position ID 288500Event WID c83c1e9e

Step 1: Create ApplicantSUCCESS

POST /ccx/service/demo_tenant/Recruiting/v44.2, status 200: Applicant ID: 184898

View the request sent to Workday

<bsvc:Put_Applicant_Request bsvc:version="v44.2">
  <bsvc:Applicant_Data>
    <bsvc:Applicant_ID>0000</bsvc:Applicant_ID>
    <bsvc:Personal_Data>
      <bsvc:Name_Data>
        <bsvc:Legal_Name_Data>
          <bsvc:Name_Detail_Data bsvc:Country_Reference="CAN">
            <bsvc:First_Name>Priya</bsvc:First_Name>

Step 2: Create PositionSUCCESS

POST /ccx/service/demo_tenant/Recruiting/v44.2, status 200: Position ID: 288500

View the request sent to Workday

Step 3: Contract Contingent WorkerSUCCESS

POST /ccx/service/demo_tenant/Staffing/v44.2, status 200: Event WID: c83c1e9e

View the request sent to Workday

01 / the form

What the agency actually fills in

One guided form, four steps. Every value in it is resolved live from your tenant at the moment the agency opens it.

WorkerIn Vendor

1Personal

2Position

3Assignment

4Review

Personal details

Tell us who is joining as a contingent worker.

Prefill from an existing Workday worker Search by name Search by first / last name / email

First Name

Priya

Last Name

Raman

priya.raman@example.com

Phone

5551234567

Country

Canada

Continue

step 2 / Position

Location, start date, end date, job profile, time type, worker type. Every value resolved live from your tenant.

step 3 / Assignment

Pick the manager. Supervisory org, company and cost centre auto-fill from that one choice.

step 4 / Review

The whole record on one screen, then submit. That is when the three transactions fire.

02 / the chain

Three operations, in order, each gated on the last

This is the whole API surface. There is no queue, no nightly file, no staging table that someone reconciles later. The vendor presses submit and WorkerIn calls Workday three times, stopping the moment a call does not come back with an identifier.

Recruiting

Put_Applicant

Create the pre-hire

Legal name, contact details and country go in as the pre-hire record that step 3 will reference. Workday renamed Applicant to Pre-Hire in the interface; the web service kept its original name.

returns Applicant_ID

gate: none. This is the entry point.

Staffing

Create_Position

Open the position

Supervisory organisation, job profile, location, time type and worker type, the same fields a Workday-native position needs. Create_Position is a Staffing operation that Workday also binds on the Recruiting service, and that binding is the endpoint WorkerIn calls.

returns Position_ID

gate: runs only if step 1 returned Applicant_ID.

Staffing

Contract_Contingent_Worker

Start the event

Links the pre-hire to the position and starts your tenant's own Contract Contingent Worker business process. From that point the event belongs to Workday, and your approvals, condition rules and routing decide what happens next.

returns Event_WID

gate: runs only if step 2 returned Position_ID.

03 / failure

There is no automatic rollback

Workday has no transaction that wraps these three calls, so neither do we, and a tool that claimed otherwise would be lying to you. If step 3 fails, the pre-hire and the position created in steps 1 and 2 are already in your tenant. WorkerIn hands back both identifiers on the failure screen so somebody can close them out, instead of leaving you to find orphaned records later.

What you get on a failure

The error Workday returned, unedited, plus every identifier created before the stop. That is enough to either fix the input and resubmit, or cancel the two records by hand.

Every ID created before the failure, on screen and in the record
The raw Workday validation message, not a rewritten summary
Which of the three operations stopped, and which never ran

Stopped at step 3 2 records left in tenant

Put_Applicant success

Applicant_ID184901

Create_Position success

Position_ID288512

Contract_Contingent_Worker failed

Validation error returned by Workday

Nothing after this point ran. Both records above remain in the tenant.

Close out 184901 and 288512, correct the input, submit again.

04 / boundaries

What it touches, and what it deliberately does not

Four boundaries, then the exact scope of the account it runs through.

business process

It starts your processes, it does not skip them

WorkerIn submits the event and steps back. Your approvals, condition rules, routing and audit trail all still apply, exactly as they would if the same transaction had been keyed in Workday by hand. Nothing is routed around.

access

Vendors never get a Workday account

An external staffing vendor sees WorkerIn and nothing else. WorkerIn reaches the tenant through a single integration system user that you create, you scope, and you can disable without anyone asking us.

resolution

Values are resolved live at submit

Location, job profile and manager are re-resolved against the live tenant at the moment of submission, not read back from a dropdown that was cached when the page loaded. A profile that was inactivated this morning fails this afternoon, which is the correct behaviour.

re-engagement

Returning workers are looked up, not retyped

A contingent worker whose contract has already ended can be found and their details copied straight into the form, so a second engagement does not mean a second round of transcription errors.

What the integration system user needs

Workday's public API documentation states Contextual Security: No Information for all three of these operations, so the exact domain security policies are derived in your own tenant rather than quoted here. This is the list to derive them from. Give it to your security lead before the call, not during it.

Writes. These three operations, and nothing else.
Operation	Service	What it does
`Put_Applicant`	Recruiting	Creates one pre-hire. WorkerIn never sends an `Applicant_Reference`, so it cannot update or overwrite one that already exists.
`Create_Position`	Staffing	Opens one position. Workday also binds this Staffing operation on the Recruiting service, and Recruiting is the endpoint called, but the domain to grant is Staffing.
`Contract_Contingent_Worker`	Staffing	Starts your Contract Contingent Worker business process.

Reads are eight report-as-a-service reports that you build and own, so the read surface is whatever you put in them, not whatever WorkerIn asks for. The worker search an agency sees is filtered to contingent workers whose contract has already ended, which is the re-engagement case, and needs at least three characters. It is not a directory of your workforce:

RPT_WorkerIn_Locations
RPT_WorkerIn_JobProfiles
RPT_WorkerIn_Managers
RPT_WorkerIn_ManagerContext
RPT_WorkerIn_ManagerSupOrg
RPT_WorkerIn_WorkerPrefill
RPT_WorkerIn_WorkerSearchFast
RPT_WorkerIn_WorkerSearch

Personal data sent to Workday: legal name, preferred name, email address, phone number, country.
Never sent, and not present anywhere in the request bodies: national or government ID, passport, visa, date of birth, gender, ethnicity, disability, veteran status, citizenship, marital status, compensation, pay rate, bank details, resume, photograph.

05 / the gap

The lane that cannot be built inside Workday

Your own managers already have a way to hire a contingent worker, whether that is an Extend app you built or a Workday-native process. The agency supplying the worker does not, and cannot be given one. That is the gap WorkerIn fills, and only that gap.

who holds it

The agency has the details

Legal name, contact details, start and end dates, the manager the worker reports to. All of it sits with the staffing agency, and none of it is in your tenant yet.

how it crosses

So it arrives as a spreadsheet

The agency has no tenant access, so the details come by email, a shared sheet or a form somebody built, and a coordinator types them into Workday by hand.

why not extend

Extend cannot close this

An Extend app is the right tool for your own managers, and plenty of teams have one. It cannot serve the agency, because Extend runs inside Workday and the agency has no Workday account.

06 / status

Where this actually is, stated plainly

You have been pitched things that were further along than they looked. Everything on this page is either running code or a stated limit, so here is the ledger.

Scope: Not a VMS. No sourcing, no rate cards, no timesheets, no invoicing, no scorecards. If your agencies already work inside a vendor management system, you do not need this.
Stage: Pre-revenue. No customers, no case studies, no logo wall, and none of those are coming until they are real.
Pricing: Not published. It has not been set, so quoting one here would be invented.
Team: One person: Imran Anwar, who wrote every line of this. The history is on LinkedIn if you want to check it.
Security: Runs on Cloudflare Workers, with the database in Cloudflare D1 in the Eastern North America region. The integration system user password is encrypted at rest with AES-GCM under a key held as a deployment secret, never in the source. Agencies cannot see each other’s submissions, because no agency can read submissions at all: only your administrator can. Vendor sessions last eight hours, and disabling an account ends it on the next request rather than at expiry. No SOC 2, no third-party penetration test, no bug bounty. Ask for detail on any of this and you will get it.
Demo: Runs against a demo tenant with sample data. The three transactions really execute. The people are not real.
Rollback: None, by design and by Workday's constraints. Documented above rather than buried.
If it stops: Your fallback is the process you run today. WorkerIn starts your own onboarding path rather than replacing it, so going back to manual entry needs nothing rebuilt and nothing migrated: the workers already in Workday stay there with their audit trail, and the agencies go back to sending you the form. You lose the time saving, not the records. There is no source escrow and no support commitment yet, because at this stage either one would be a promise I could not back.

07 / request

See it run against a demo tenant

About twenty minutes. Tell me what your vendors do today and I will show you the parts that matter to you rather than a generic tour. You will see the three calls fire and the identifiers come back.

This reaches one person, is used only to reply, and is never passed on.