ServiceNow Workday integration

• ServiceNow: admin, IntegrationHub, Workday spoke, and HR Service Delivery.
• Workday: an Integration System User (ISU) with a security group granting the needed domains.
• The Workday tenant, WSDL/REST endpoint, and (optionally) a report-as-a-service (RaaS) URL.

Two decisions matter more than any configuration step, and both are difficult to reverse later.

Workday is the system of record for people. That means it owns names, employment status, job, department, manager and dates. ServiceNow owns what is specific to the platform: roles, assignment groups, preferences. If both write the same attribute, one overwrites the other on every sync and nobody can say which is correct.

Pick a matching key that does not change. There has to be one attribute identifying the same person in both systems. Email address is the obvious choice and a poor one, because people change names. The Workday worker identifier is stable and is the right answer where you can carry it. Getting this wrong produces duplicate user records, and duplicates are painful to unpick once incidents and approvals reference them.

• In Workday, create an ISU and add it to an Integration System Security Group with access to Staffing/Personal Data.
• Enable Do Not Allow UI Sessions and set a strong password; note the credentials.

The principle behind the integration system user is worth stating because it applies to every integration you will build, not just this one. It is an account that belongs to the integration rather than to a person, with a security group granting exactly the reports and web services this integration calls and nothing else. That gives you three things: the ability to attribute volume and errors to one integration, the ability to rotate its credentials without affecting anybody, and a much smaller problem if the credentials leak.

The shortcut people take is reusing an existing account with broad rights because it already works. It does work, and it makes every subsequent question about who did what unanswerable.

• Install the Workday spoke.
• Create a Basic Auth credential (ISU@tenant) and a Connection to the Workday endpoint; attach to the spoke alias.

Workday Worker              ServiceNow (sys_user / hr_profile)
Worker_ID               ->  employee_number
Legal_Name              ->  name
Primary_Work_Email      ->  email
Manager_Reference       ->  manager
Hire_Date               ->  u_hire_date
Termination_Date        ->  (drives deactivation)

Two rules keep the mapping maintainable. Map the minimum, because every attribute you sync is one more thing that can be wrong, and most ServiceNow processes need far fewer fields than people assume. And be careful with references: the manager field points at another user record, so it only resolves if that person has already been synced. New starters whose manager joined the same week are the case that exposes this, and the symptom is an empty manager on exactly the records where an approval needed one.

Half a day against a Workday sandbox, and it surfaces the problems before real people do.

1. Sync a single test worker and confirm the ServiceNow user record has the fields you expect and nothing you did not ask for.
2. Change a field in Workday and run the sync again. Confirm it updates the same record rather than creating a second one. This is the matching key test.
3. Change the worker's manager to somebody not yet synced. See what the manager field does.
4. Terminate the worker in Workday and run the sync. Decide, and then verify, whether the ServiceNow record is locked or deleted.
5. Rehire the same worker and sync again. Does the old record come back, or is there now a second one.
6. Look at how long a full sync takes against your real headcount, not against one test worker.

Steps four and five are the ones nobody runs before go live and both are things an auditor will ask about. See the Okta integration for the same questions asked of a directory.

• Build a flow that calls Get_Workers (or a RaaS report) on a schedule (e.g. every 15 min) filtered by last modified.
• Upsert sys_user keyed on employee_number; create HR profiles for new hires.
• For near real time, subscribe to Workday notifications/EIB that POST to a ServiceNow Scripted REST endpoint.

The two mechanisms answer different needs and most implementations want both. Scheduled sync is the safety net: it catches everything, including changes an event missed, and it is what you rely on for correctness. Event driven sync is for latency: a termination should not wait for tonight's run.

The decision to make explicitly is the schedule frequency, and it is a risk conversation rather than a technical one. A nightly full sync means a leaver can retain access for most of a day. Hourly reduces that and costs more load. Whatever you choose, it is worth writing down what the exposure window is, because somebody will eventually ask and the honest answer should not be a surprise.

• When a new worker with a future hire date appears, kick off the HRSD onboarding lifecycle case and its tasks.
• On termination date, trigger offboarding and downstream de-provisioning (e.g. via SailPoint/Okta).

The trap worth naming here is timing. A new hire usually exists in Workday well before their start date, so an onboarding process triggered on record creation runs weeks early, and access provisioned then is access granted to somebody who has not arrived. Trigger on the start date, or on a defined number of days before it, and treat that offset as a deliberate decision rather than an accident.

• Hire a test worker in Workday sandbox; confirm the user + onboarding case appear.
• Terminate the worker; confirm offboarding fires.

Stage the rollout rather than switching it on. Sync a small set of workers first and check them by hand. Then widen to one department. Then everybody, with the onboarding trigger still disabled. Then enable onboarding for new hires only. Each stage has a population small enough to inspect and an obvious way back, which is what you want the first time a real HR system meets a real instance.

• Empty results: ISU security group missing a domain.
• Duplicates: coalesce on employee_number.
• SOAP faults: verify the Workday API version in the endpoint URL.

Three symptoms cover most of what goes wrong, and each has a different first check.

Duplicate users. The matching key changed or was not unique. Fix the key before merging the duplicates, otherwise you will be merging again next month.

Fields blank on some records only. Almost always a reference that did not resolve, most often the manager, because of ordering.

Nothing syncing at all, no errors. The integration user's credentials expired, or the scheduled job is not running. Silence is the failure mode to have monitoring for, because error based alerting is quiet precisely when the integration has stopped entirely.

Version note: Workday revises its web service API on a published schedule and older versions are retired, so an integration configured against a specific version will eventually need to be moved. Track which version yours uses and treat the retirement dates as planned work rather than as an incident. On the ServiceNow side the spoke and its actions have also been revised, so a named screen may differ on your release. See the Slack integration, the Jira integration and the Dynatrace integration.

• Matching on an attribute that changes. Duplicate users.
• Both systems writing the same field. It flips on every sync.
• Onboarding triggered on record creation. Access weeks before the start date.
• Never testing termination and rehire. The two an audit asks about.
• No alert on silence. A stopped integration produces no errors.

Wiring the sync takes a day, and designing the ownership, matching and timing so it still works after a reorganisation is the judgement the course builds.