Integrate with Workday

Follow this step-by-step guide to let SlashID read your Workday tenant directly. Workday is treated as the HR system of record: every worker becomes a person SlashID can match to their accounts in your other systems, and hires, job changes and terminations drive joiner, mover and leaver events — including terminations that have been entered but have not taken effect yet.

Preview

This is a native integration that reads Workday's Human Resources web service with an Integration System User. A new connection always starts in dry run, so you can check what SlashID reads before anything is imported.

Before starting

Before starting, ensure you have:

• A Workday administrator who can create Integration System Users, security groups and edit domain security policies.
• Your tenant's web-services host and tenant name. Both appear in any of the tenant's web-service endpoints: in https://wd2-impl-services1.workday.com/ccx/service/acme_prod/Human_Resources, the host is wd2-impl-services1.workday.com and the tenant name is acme_prod. You can find an endpoint with the Public Web Services report → Human Resources → View WSDL.

Step 1: Create an Integration System User

1. Run the task Create Integration System User.
2. Choose a user name (for example ISU_SlashID) and a strong password.
3. Leave Require New Password at Next Sign In unchecked.
4. Tick Do Not Allow UI Sessions: the account is only ever used by the web service.

danger

Workday expires passwords by default, including an Integration System User's. Either exempt the account (Maintain Password Rules → System Users exempt from password expiration) or plan to rotate the password in the SlashID Console before it expires. After a few refused sign-ins Workday locks the account.

Step 2: Create a security group

1. Run the task Create Security Group.
2. Type: Integration System Security Group (Unconstrained). Name it, for example, ISSG_SlashID.
3. Add the Integration System User from step 1 as a member.

A constrained group works too, but SlashID then only sees the workers of the organizations the group is constrained to.

Step 3: Grant the group read access

For each of the following domains, run View Domain, open Domain → Edit Security Policy Permissions, and add the group under Integration Permissions with Get access only:

Domain	What SlashID reads through it
Worker Data: Public Worker Reports	The list of workers and their IDs
Worker Data: Current Staffing Information	Hire and termination dates, position, job profile, manager
Worker Data: Organization Information	Supervisory organization and cost center
Person Data: Work Contact Information	Work email address
Worker Data: Historical Staffing Information	The worker transaction log (HR events), optional

Domain names vary slightly between tenants and Workday releases. If a name above does not exist in yours, the connection's health check (step 5) tells you which data is missing.

Do not grant personal-information domains

SlashID needs work contact data only. Do not grant domains such as Person Data: Personal Information, Person Data: Home Contact Information, Person Data: ID Information or anything covering compensation or government IDs. The integration does not use them, and Workday returns whatever the group is allowed to see.

Step 4: Activate the security policy changes

Run the task Activate Pending Security Policy Changes. Until you do, none of the grants from step 3 have any effect — this is the most common reason for a failing health check.

Step 5: Create your Workday ↔ SlashID integration

1. Go to the SlashID Console integrations page.
2. Click Add data source and select Workday.
3. Enter your connection details:

SlashID Console field	Description	Example
Name of the connection	Arbitrary name you give to this connection	Workday Production
Web-services host	The host of your tenant's web-service endpoints. Must be a Workday domain	wd2-impl-services1.workday.com
Tenant name	Your tenant name. Cannot be changed later	acme_prod
Authentication	Integration System User (username and password) or API client (OAuth refresh token)	—
Username	The Integration System User's name, without @tenant	ISU_SlashID
Password	The Integration System User's password	—
Import	Leave off when creating the connection (see below)	—
Authoritative status	Whether Workday is the primary source of truth when reconciling identities across providers	Primary

4. Click Connect. The first sync is a dry run: SlashID reads your tenant and imports nothing.
5. Open the connection's Health check tab. Alongside the permission checks, the Dry-run report lists how many workers were read, how many are terminated or have a pending termination, how many are contingent, and how many have no work email or no manager.
6. If those numbers match your tenant, edit the connection, turn Import on, and sync again.

A dry-run sync is shown as failed in the connection's sync history, with the message "Dry run complete". That is expected: a failed sync is the one outcome that is guaranteed to import and remove nothing.

Using an API client instead of a password

If you prefer OAuth, register an API Client for Integrations in Workday with the scopes Staffing, Organizations and Roles and Contact Information, generate a non-expiring refresh token for the Integration System User, and select API client under Authentication. The domain grants in step 3 are still required.

If this tenant is already connected to SlashID

There is nothing to configure. When the first sync finds that the people it read from Workday are the people SlashID already imported for this tenant, it carries on from them:

• People keep the identities, tags and history they already have: the native connection produces the same person IDs.
• While the native connection is syncing, the older connection's own scheduled sync is on hold, so the two do not overwrite each other. It resumes by itself within two days if the native connection stops syncing or is deleted.

If SlashID cannot tell whether an existing connection reads the same tenant, the sync stops without importing anything and the health check says why.

Checks before every import

Before every import, SlashID checks that what it read from Workday is plausible: no sudden drop in headcount, no spike in terminations, the same people as the last import. A sync that fails those checks never removes anyone. The health check's Source of the last sync item tells you when that happened and why.

What SlashID collects

• Workers (employees and contingent workers): name, work email, employee ID, worker type, hire date, termination date and reason category, position and business title, job profile, location, cost center, manager.
• Supervisory organizations, as groups with their members.
• HR events, read from each worker's transaction log as they are entered: hires, terminations, job changes and any other business process recorded against a worker. A termination entered today for a date next month is visible today.

SlashID never writes to Workday.