[object Object]

The new hire’s manager in ServiceNow is the person they replaced six months ago. The org chart in HR Service Delivery routes approvals into a void. The Workday feed runs nightly and looks healthy in the integration logs. The data drift is real and the integration is not the whole story — the data model on the ServiceNow side is fighting Workday’s source-of-truth role.

Decide source of truth at the field level

Worker, manager, location, cost center, job code — Workday owns these. Skills, certifications, support group membership — ServiceNow can own these. Photo, communication preferences — could go either way. Pick per field, document it in a data ownership matrix, and build the integration to enforce it. Bidirectional editing of the same field with no clear owner produces drift you cannot debug six months later.

field_ownership:
  user.first_name -> Workday (read-only in SN)
  user.manager -> Workday (read-only in SN)
  user.cost_center -> Workday (read-only in SN)
  user.support_groups -> ServiceNow
  user.skills -> ServiceNow
  user.profile_photo -> Workday with SN override

Use the right Workday API

Workday has multiple APIs — the SOAP-based Public Web Services, the REST-based Workday APIs, and the Reports-as-a-Service (RaaS) feeds. For bulk daily sync, RaaS with a custom report tuned to deliver only changed records since last run is the most efficient. For real-time onboarding events, use Workday’s outbound EIB or webhook capability where available. SOAP for everything is the default and the most painful at scale.

Worker termination is the gnarliest case

A terminated worker should: lose access immediately, retain audit history, transfer ownership of assigned items, and not appear in active user lookups. The Workday termination event needs to fan out to deactivate sys_user, reassign open task records, transfer asset ownership, and leave audit trails intact. A simple “set active=false” cascades into broken assignments and orphan records.

// On Workday termination event
function processTermination(workerId, lastDay) {
  var user = getUserByEmployeeId(workerId);
  reassignOpenTasks(user.sys_id);
  transferAssetOwnership(user.sys_id, user.manager);
  scheduleDeactivation(user.sys_id, lastDay);
  notifyDownstreamSystems(user.sys_id, 'terminated', lastDay);
}

Future-dated changes need staging

A promotion effective in three weeks should not change the manager today. Workday emits future-dated events; the integration should stage them in a worker_change_pending table and apply on the effective date. A scheduled job runs at midnight UTC, applies pending changes whose effective date has arrived, and emits notifications to affected groups. Applying immediately breaks the entire month’s pre-effective-date approval routing.

Reconciliation, not just sync

A nightly delta sync drifts. Run a weekly full reconciliation: pull every active Workday worker, compare against sys_user, log every discrepancy in a reconciliation table for review. The reconciliation should not auto-correct everything — some discrepancies are legitimate (contractor exceptions, dual-employment) and need human review.

Org chart depth and matrix structures

A worker can have a primary manager, a dotted-line manager, and a project lead — all valid in Workday’s matrix model. ServiceNow’s sys_user.manager is a single field. Decide which Workday relationship is the primary, store the others in custom fields, and surface them in the workspace. Approval workflows must explicitly choose primary or matrix; defaulting to primary silently routes around the matrix.

Common failure modes

Employee ID format changes during M&A — version your worker key field and keep both old and new IDs queryable for 12 months. Workday calculation rules used as the authority for derived fields like cost center hierarchy — recompute on the SN side rather than caching the Workday answer. Inactive workers reactivated for boomerang hires — the integration must reuse the existing sys_user record, not create a duplicate.

Implementation sequence

Pilot with one organization unit for 30 days, validate every termination, transfer, and new hire end-to-end. Add a second org unit only after the first is clean for two weeks. Big-bang cutovers across the entire population produce silent data drift that takes a year to surface.

What to do this week: pull sys_user records where manager references an inactive user — that count is your current org-chart drift baseline.

[object Object]
Share