QAD and Workday HCM integration
QAD runs manufacturing and finance. Workday HCM runs the workforce, the org structure, and the cost centers that finance reports against. Connecting the two keeps QAD's headcount and cost center dimensions aligned with the Workday system of record, so labor allocations and workforce reporting in QAD reference the same structure HR maintains. Workday holds both HCM data over REST and finance and procurement data over SOAP, so the connection can grow from worker and org alignment into supplier and GL reads as needed. ml-connector handles the two very different authentication paths on the Workday side and moves the data on a schedule you control.
What moves between them
The main flow runs from Workday HCM into QAD. ml-connector reads worker records so QAD reflects current headcount and Workday hires, terminations, and rehires, and reads organizations and cost centers so labor allocations in QAD land on dimensions that match Workday. Cost centers and supervisory organizations are aligned so every payroll or labor journal line in QAD references a dimension that already exists. Where finance reads are enabled, supplier and purchase order records can be pulled from Workday over SOAP, but QAD remains the system of record for manufacturing and finance, so ml-connector does not write financial entries back into Workday by default.
How ml-connector handles it
ml-connector stores both credential sets encrypted and accepts the full tenant host and tenant name for Workday, since Workday publishes no shared base URL. For REST worker and organization reads it exchanges the stored refresh token for a 60-minute access token and refreshes when a call returns 401, and for finance reads it sends the ISU username and password in the SOAP WS-Security header. A missing API Client scope or security group grant returns 403 rather than 401, so it surfaces that as a permissions problem instead of retrying blindly. Because Workday has no webhooks, the connector polls on a schedule, storing a last sync timestamp per entity and querying for records updated since that point. Get_Supplier_Invoices does not support a date filter, so where invoices are read it performs a full pull and diffs locally. Cost centers and supervisory organizations are matched first so every worker and journal line maps to a QAD dimension that already exists. SOAP Submit operations create duplicates on resubmission, so ml-connector deduplicates on an external reference before any write, and it backs off with jitter on every HTTP 429, honoring the Retry-After header. Every record carries a full audit trail and can be replayed if a downstream call fails.
A real-world example
A mid-sized discrete manufacturer of industrial components, roughly 800 employees across three plants and a head office, runs QAD Adaptive ERP for production, procurement, and finance, and Workday HCM as the system of record for its workforce and org structure. Before the integration, HR maintained supervisory organizations and cost center assignments in Workday, while a finance clerk re-keyed the same structure into QAD whenever a plant reorganized or a worker changed roles, and the two drifted apart between updates. With QAD and Workday HCM connected, worker and organization changes flow into QAD on a schedule, and cost centers stay aligned, so labor reporting in QAD reflects the current org without manual re-entry and month-end allocations hit valid dimensions.
What you can do
- Read workers, organizations, and cost centers from Workday HCM into QAD on a schedule.
- Keep QAD headcount aligned with Workday HCM hires, terminations, and rehires.
- Align QAD cost centers with Workday supervisory organizations and cost centers so labor lands on valid dimensions.
- Authenticate Workday HCM with OAuth 2.0 refresh tokens for REST and ISU WS-Security for SOAP, and QAD with its tenant-specific token.
- Poll Workday on a delta timestamp with backoff on 429, retries, and a full audit trail on every record.
Questions
- Which direction does data move between QAD and Workday HCM?
- The main flow is Workday HCM into QAD. Worker, organization, and cost center records move from Workday into QAD so headcount and labor dimensions stay aligned with the HR system of record. Where finance reads are enabled, supplier and purchase order data can also be pulled from Workday over SOAP, but QAD stays the system of record for finance, so ml-connector does not write financial entries back into Workday by default.
- How does ml-connector authenticate to Workday HCM?
- Workday uses two auth paths, and a full integration needs both. The REST API for workers and organizations uses OAuth 2.0 with a long-lived refresh token that mints a 60-minute access token, while the SOAP services that cover finance use Integration System User credentials in a WS-Security header. ml-connector stores both sets encrypted, targets the tenant-specific Workday host and tenant name you provide, and refreshes the access token before it expires.
- Does the integration use Workday webhooks or polling?
- It uses polling. Workday has no native webhooks and offers no way to register a callback URL for HR or finance events. ml-connector pulls on a schedule, stores a last sync timestamp per entity, and queries for records updated since that point, falling back to a full pull and local diff for Get_Supplier_Invoices because it has no date filter. It backs off with jitter and honors the Retry-After header whenever Workday returns HTTP 429.
Related integrations
More QAD integrations
Other systems that connect to Workday HCM
Connect QAD and Workday HCM
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started