Sage X3 and Workday HCM integration

What moves between them

The main flow runs from Workday HCM into Sage X3. Worker records, positions, and organizations move from Workday into Sage X3 as customers and GL cost center references. Cost centers and departments are aligned in both directions so payroll allocations land on valid Sage X3 GL accounts. The sync runs on a schedule tied to your payroll calendar rather than relying on a push from Sage X3, which is poll-only.

How ml-connector handles it

ml-connector stores Workday SOAP credentials encrypted and uses the Workday SOAP API (WS-Security UsernameToken) to read workers and cost centers, refreshing the SOAP session token when needed. On the Sage X3 side it accepts the full instance URL, port, and folder name per customer, since Sage X3 publishes no shared base address. For REST api1 it presents HTTP Basic Auth; for GraphQL it uses OAuth2 client credentials. Because both systems are poll-only, ml-connector polls Workday HCM and Sage X3 on a schedule tied to your payroll calendar. Cost centers and organizations are mapped first, so every worker record references a GL account and cost center that already exists in Sage X3. Sage X3 access tokens expire in 5 minutes, so ml-connector refreshes them before they expire. Workday rate limits trigger HTTP 429, so ml-connector backs off and retries using the Retry-After header. Every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-market distributor runs Sage X3 for finance, procurement, and inventory across three regional warehouses, and uses Workday HCM for payroll and workforce management. Before the integration, the finance team manually exported worker data from Workday every pay period and entered new hires and terminations into Sage X3 by hand, then spent time at month-end close chasing differences between Workday headcount and the labor accounts in the ledger. With Sage X3 and Workday HCM connected, each payroll cycle's worker changes flow into Sage X3 automatically, allocated to the cost center for each warehouse, and the labor costs are tied to the correct GL accounts. Month-end close starts with headcount already reconciled, and the manual re-entry step is gone.

What you can do

• •Sync Workday HCM worker records, positions, and organizations into Sage X3 on a payroll schedule.
• •Map Workday cost centers and departments to Sage X3 GL accounts so labor allocations land on valid dimensions.
• •Authenticate Workday HCM with SOAP WS-Security UsernameToken and Sage X3 with OAuth2 or HTTP Basic Auth.
• •Refresh Sage X3 access tokens before expiry and handle Workday rate limits with automatic backoff and retry.
• •Keep a full audit trail on every record and replay any record if a downstream write fails.

Questions

Which direction does data move between Sage X3 and Workday HCM?

The main flow is Workday HCM into Sage X3. Worker records, positions, organizations, and cost centers move from Workday HCM into Sage X3, while cost centers and departments are aligned in both directions. Sage X3 GL account postings are read-only in Workday, so ml-connector does not write financial entries back into payroll.

How does ml-connector handle Sage X3 and Workday authentication?

ml-connector stores both credential sets encrypted. For Sage X3 it accepts the full instance URL and port per customer and supports both OAuth2 (GraphQL) and HTTP Basic Auth (REST api1). For Workday HCM it uses the SOAP WS-Security UsernameToken authentication method to read worker and cost center data, refreshing the session token when it expires.

How does the integration handle the lack of webhooks in both systems?

Both Sage X3 and Workday HCM are poll-only, so ml-connector polls both systems on a schedule tied to your payroll calendar rather than waiting for a push. Sage X3 access tokens expire in 5 minutes, so ml-connector refreshes them proactively. Workday rate limits trigger HTTP 429, so ml-connector backs off and retries using the Retry-After header.