Workday (platform)
Workday is the worker and staffing system of record. VMS Agent contracts contingent workers through the Staffing business-process operations; writes are largely SOAP-only, while reads are available via REST and RaaS.
The public API facts VMS Agent's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.
| Authentication | OAuth 2.0 (auth-code + ISU client-credentials) for REST; WS-Security or OAuth via an Integration System User (ISU) for SOAP. Access tokens ~1h; non-expiring refresh tokens configurable. |
|---|---|
| API style | SOAP (Workday Web Services — primary), REST/JSON (partial subset), RaaS (reports-as-a-service) |
| Base URL | REST https://{host}/ccx/api/{service}/v{n}/{tenant} | SOAP https://{host}/ccx/service/{tenant}/{WebService}/v{n} |
| Objects | Staffing (Create_Position, Contract_Contingent_Worker, End_Contingent_Worker_Contract), Job Requisition, Position, Worker, Supplier, Purchase Order |
| Events / webhooks | No native webhooks. Event-driven via the Business Process Framework, EIB outbound, Studio and Extend. RaaS is poll-based. |
| Rate limits | Not officially published; practitioner ~10 req/s per tenant, HTTP 429 + Retry-After. Queue + exponential backoff. |
“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary — especially around custom fields, approval flows and object extensions.
Deterministic mapping
Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).
Tenant discovery
VMS Agent can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.
Enrichment loop
If the target platform requires a field the Intent record doesn't yet have, VMS Agent emits an enrichment_request back to the intake layer.
An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.
| Object | Canonical fields | Platform target | Required status | Notes |
|---|---|---|---|---|
| Contingent worker (contract) Onboard external worker |
worker, position, start_date, supplier, job_profile | Contract_Contingent_Worker (Staffing SOAP BP) | Required + tenant BP | Approvals run via the tenant business process |
| Position (create) Create the headcount |
role_title, org, location, headcount | Create_Position (Staffing SOAP) | Required | Precedes contracting |
| End contract Offboard / liveness |
worker_id, end_date, reason | End_Contingent_Worker_Contract | Required | Drives liveness + offboarding |
Idempotency & drift — publish + reconcileExpand
Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, VMS Agent supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.
Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). VMS Agent is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.
How scanning works
High-level flow
What gets produced
Portable artefacts
Important — where this platform is tenant-definedExpand
Pin a WWS version (e.g. v46.1) in every endpoint. Requires an ISU + integration security group + registered API client. Implementation and production tenants use different hosts.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.