Platform access level: Org Admins
Connecting Workday to Arist keeps your learner roster current without anyone exporting a file. New hires, profile changes, and departures flow into Arist on a daily schedule, so the right people are always reachable for training. This guide covers the inbound worker sync, the live production path today, and is written for the IT and Workday administrators who set it up.
1. Inbound worker sync overview
Arist reads worker data from your Workday tenant over its web services, authenticated with OAuth 2.0 against a dedicated Integration System User (ISU). The primary feed is a Custom Report-as-a-Service (RaaS) you define, supplemented by Get_Workers for manager, organization, location, and job metadata. Arist uses this data to create learners, segment audiences, and trigger automations.
Note: Writing the courses and completions Arist generates back to Workday Learning is a separate outbound flow, covered under Related articles.
2. Before you begin
Confirm these items in the weeks before your setup session, since each is an access grant or a decision that can take time to settle. Loop in your Workday tenant, HRIS, and security teams early.
Item | What to confirm |
Integration System User created | A dedicated ISU for the integration to run as, with a non-expiring or rotation-managed password and a security group of its own. |
API client for integrations registered | An API Client for Integrations registered against the ISU. Capture the client secret and refresh token at creation, since the secret cannot be retrieved later. |
Tenant details confirmed | The Tenant ID, OAuth authorization and token endpoints, and the Workday Web Services version your tenant runs, for example v44.1. |
RaaS custom report built and exposed | The custom report that serves as Arist's worker feed, exposed as a web service under the ISU. Its |
HRIS metadata fields selected | Decide which worker fields Arist receives, and confirm they are populated and included as report columns, or covered by a domain granted to the ISU. |
Endpoints reviewed with security | Share the endpoint list with your security team, and apply any IP allow-listing your policy requires. |
3. Decisions to settle before mapping
These questions define who syncs to Arist and what happens when a worker's situation changes. They are the items most likely to surface mid-project if they are not decided up front, so bring answers to your first session.
Question | What to decide |
Which worker populations are in scope | Whether the custom report includes full-time only, or also part-time, seasonal, and contingent workers, and confirm its filters match. |
When new hires enter the feed, and whether they arrive complete | Decide at what point in onboarding a new hire is added to the report, and whether they arrive with a work email or are provisioned without one first. A worker sent before their email is populated cannot be reached and is filtered out until the email is added on a later sync, which delays when Arist can start training them. Confirm whether records are sent only once complete, or sent early and expected to become reachable later, and agree the acceptable lag. |
What happens when a worker changes employment type | Conversions often issue a new Worker ID in a different format, so decide which record wins and whether learning history follows the person. |
How active and inactive workers are handled | Map employment status as a synced field, and decide whether a worker on leave keeps receiving training, pauses, or deactivates. |
What happens at termination and rehire | How quickly messages stop, whether the learner record deactivates or is removed, and whether a rehire reuses the same Worker ID or a new one. |
Which email is authoritative | Workday email, Microsoft UPN, and contact email can differ, so name the system of record, the update lag, and which address reaches each worker. |
What other systems create or update users | If Teams or a device-management sync also provisions learners, list every source and the identifier each keys on so no one arrives twice. |
Whether legacy, shared, or generic emails exist | Acquired-company domains, regional domains, and shared mailboxes break one person to one email, so skim the report and decide how each is reconciled. |
How fresh the data must be | Agree a sync frequency that matches how fast your workforce changes. Daily is typical, so say so now if transitions must reflect within hours. |
Who is excluded | Executives, unions, specific countries, or workers without corporate email are easiest to handle as report filters, so name them now. |
4. Credentials your IT team provides
Your IT team provides the eight values below, generated and located inside your Workday tenant under the Register API Client for Integrations task and your tenant URL.
Field | What it is | Where to find it |
Tenant ID | Your Workday tenant identifier | In your Workday URL: |
WSDL URL | The endpoint Arist reads worker data from (your RaaS report) | The custom report's web-service URL with |
Client ID | The OAuth API client (application) identifier | Workday, View API Clients task |
Client Secret | The secret paired with the Client ID, shown once | The same Register API Client task, captured once at creation |
Refresh token | Long-lived token bound to the ISU | From authorizing the ISU under API Clients for Integrations |
Authorization endpoint | OAuth authorize URL for your tenant |
|
Token endpoint | OAuth token URL for your tenant |
|
Web services version | The Workday Web Services (WWS) version Arist calls | Current tenant version, for example v44.1 |
Important: Create a dedicated ISU, then register an API Client for Integrations against it, and capture the client secret and refresh token at creation, because the secret cannot be retrieved later. The connection type is Cloud unless you use an on-prem agent.
5. Endpoints Arist reads
Arist reads worker records and their HRIS metadata primarily through the RaaS custom report you expose, supplemented by two web services.
Purpose | Endpoint |
Worker feed, RaaS custom report |
|
Worker records and HRIS metadata |
|
Resolve and validate a worker | Workday Query Language (WQL) or Staffing REST, by Employee ID |
The ?wsdl form of the same custom report is the connection's WSDL URL, Get_Workers supplements the report with manager, supervisory org, location, and job metadata, and WQL or Staffing REST resolves an individual worker by Employee ID.
6. HRIS metadata fields
The metadata Arist reads is what it uses to create learners and segment audiences, so any field you want to target on has to be available. Commonly mapped fields are Employee ID (Worker ID), Email, Manager, Supervisory org, Cost center or Department, Company or Business unit, Job profile or Business title, Job code, Location, Country, Hire date, Worker type, Employment status, Preferred language or locale, and custom and calculated fields.
Important: Worker type and employment status drive the lifecycle decisions in section 3, so include them even if you do not target on them. Confirm each field is populated and included as a report column, or covered by a granted domain. A field that is not is not visible to Arist and cannot be used for targeting.
7. How the daily sync runs
The worker sync is fully automated and runs once a day, moving through three lanes: your Workday tenant, an integration layer that transforms and validates, and the Arist platform that provisions learners. A typical run processes 500 to 1,250 workers per batch.
Your Workday RaaS custom report is scheduled to run daily, for example at 3:15 AM Pacific, and the integration layer picks it up on a scheduled trigger.
A pre-flight validation guard filters out any record with a missing email or an unknown time zone before processing.
The batch is transformed: emails are normalized, an IANA time zone is derived, names are split, and an inactive employment status is mapped to an inactivation timestamp on the learner.
A failure gate stops the run on hard errors, tolerates a 404, and retries a transient failure twice.
Arist performs a bulk upsert that maps the worker and manager identifiers to learner records, and returns the successful and failed records for the run.
Note: If a run stops, Arist alerts its integration support team with the flow name, the error, and the failing records. An optional per-customer job-results email can summarize each run as created, updated, inactivated, and failed counts.
8. Matching workers on a stable identifier
Arist matches each learner on a stable key that survives job changes, transfers, and rehires, which is the Employee ID or Worker ID rather than email. Confirm that key is consistent across your systems, since a conversion that issues a new Worker ID can split one person into two learner records unless you decide how it is handled.
If another system such as Teams also provisions learners into Arist, agree which identifier each source keys on, so the same person is never created twice.
Related articles
LMS Integration - Workday
Arist and Workday - Technical Guide
HRIS Data Preparation
Note: Need help at any point? Reach out to your Arist Customer Success contact, or email [email protected].