Workday VNDLY (platform)

Workday VNDLY is a cloud-native VMS aligned to the Workday suite. VMSagent treats VNDLY as a destination system of record: it publishes intent records and keeps an audit spine, while tenant mapping is validated in a customer sandbox/tenant.

Readiness
Docs confidence: Customer

“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, VMS 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).

Tenant discovery

VMSagent 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 that the Intent record doesn’t yet have, VMSagent emits an enrichment_request back to the intake layer.

Quality note — accuracy boundariesExpand

This page is written to be implementation‑useful but not vendor‑certified. For any tenant build, the MappingProfile must be validated against a sandbox/tenant and your program’s required fields.

Mapping
Minimum viable mapping for Workday VNDLY (platform)

Below is 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
Requisition (Contingent)
Create worker request
role_title, location, start_date, cost_center, worker_type Customer API (Workday ecosystem) Tenant required Workday alignment drives required fields
Worker / Assignment
Assignment lifecycle
worker_id, dates, rate, status Customer API Tenant required Back-sync into intent timeline
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 VMS, VMSagent supports reconciliation: it compares the VMS record snapshot to the canonical intent and flags drift.

Tenant specifics
Custom fields & unique mapping

Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules, or supplier constraints). VMSagent is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.

How scanning works

High-level flow

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)
Important — where scanning may be limitedExpand

Workday VNDLY documentation is often customer/partner-scoped. VMSagent therefore starts with minimum viable mapping and relies on tenant discovery (required fields, custom fields, code lists) to generate a working MappingProfile.

Next
Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync, and reconciliation.