Skip to main content

Connect Workday

Import your workers and their job history from Workday. You connect Oho to Workday once, and Oho creates your workers and keeps them in step with Workday on the schedule you choose — so people don't have to be added in two places.

Because Oho reads Workday directly, there's no file to build or host: new starters, role changes, and leavers in Workday flow through to Oho on their own.

What you'll end up with

Your whole workforce in Oho — each person a worker, with their credentials added and checked — kept in step with Workday, without maintaining two lists.

Before you start​

You'll need:

  • Your workers already recorded in Workday, with the details you want in Oho — names, dates of birth, organisation, job history, and any card or registration numbers.
  • A Workday administrator, or someone who has that access, to create the integration account and grant its access in Step 1. This is a Workday configuration task, so loop in whoever administers your tenant if that isn't you.
  • Your Workday tenant and web-services endpoint, which identify your account and tell Oho where to connect (see Step 1).
  • The credential types you plan to verify in Oho, so you can map Workday's qualifications to them in Step 3.

Step 1: Get your auth details​

What you'll need for this step

A Workday administrator to create the connection. The details below are set up inside Workday, not in Oho — if you don't administer Workday yourself, loop in whoever does.

Oho connects to Workday through an Integration System User (ISU) — a dedicated, non-human account your administrator creates for the connection — together with your tenant and web-services endpoint. Your administrator sets up the ISU, grants it read access to the workers and fields Oho imports, and gives you the connection details to paste into Oho in Step 2.

  1. Sign in to Workday as an administrator.
  2. Create an Integration System User (ISU) dedicated to Oho, so its access is separate from any person's account and easy to audit or revoke.
  3. Grant the ISU read access to workers and job history through a security group scoped to just the people and fields Oho imports.
  4. Note the tenant and web-services endpoint for your Workday account.
  5. Generate the ISU's credentials to enter alongside the tenant and endpoint in Oho.

For the shared version of this pattern, see Get your auth details — Workday uses a dedicated service account rather than an app sign-in.

Technical detail: ISU, security group, scopes & endpoint

Hand these points to whoever administers Workday — a non-technical admin can skip them.

  • Authentication mechanism. WS-Security UsernameToken in the SOAP header. Oho sends the ISU username qualified with your tenant as isu@tenant, together with the ISU password. There is no OAuth flow and no app sign-in. In Step 2, Oho asks for the ISU username, the ISU password, your tenant, and the web-services host.
  • Integration System User (ISU). Create a dedicated ISU for Oho rather than reusing a person's account, and set its password not to expire (or track the expiry so the connection doesn't lapse). A person's account changing or leaving then can't break the sync.
  • Security group & least-privilege scope. Put the ISU in an Integration System Security Group with read-only access to the domains behind the Get_Workers operation of the Human Resources web service: worker data, personal data, employment data, organisations, and the identification and qualification domains for the record types you plan to map. Oho calls Get_Workers and nothing else — no RaaS report, no WQL, no REST API, and no write operation of any kind. Remember to activate the pending security policy changes.
  • Tenant & endpoint. Oho needs the services host and the tenant, both readable from your web-services URL. For https://wd2-impl-services1.workday.com/ccx/service/acme_co, the host is https://wd2-impl-services1.workday.com and the tenant is acme_co. Use the services host, not the login or identity host. Oho defaults to Workday Web Services v44.1; set a different version in the connection if your tenant needs one.
  • What Oho reads. Only the fields it asks for: worker identity (name, work email, date of birth), position and employment (title, start date, termination date, worker type, location, manager), organisation assignment, and the licence, certification, passport, visa and government-ID records whose type you map in Step 3. Compensation, payroll, benefits, absence, performance, time tracking and document attachments are never requested.
  • Credential storage. The ISU credentials are stored encrypted in Oho and sent on each request over TLS. They are never shown back in the UI or written to logs.
  • IP allow-list. Oho connects outbound only — Workday never calls Oho, so no inbound rule is needed. If your tenant restricts web-services access by IP, contact support@weareoho.com for the egress address to allow.
  • Request volume. Oho rate-limits itself to 8 requests/second (Workday allows roughly 10/second per tenant) and retries a throttled or failed request up to 3 times, honouring Retry-After. Workers are fetched in pages of 100.
Treat the ISU credentials like a password, and rotate them

The ISU credentials grant ongoing access to worker PII for as long as they're valid.

  • Never post them in email, chat, or a ticket, and hand them over only through a channel your organisation trusts.
  • Rotate the credentials periodically, and whenever someone with access to them leaves.
  • To rotate without downtime: set the new credentials on the ISU, update them in the integration's settings, then retire the old ones in Workday.

Expected outcome: you have the ISU credentials plus your Workday tenant and endpoint copied, ready to paste into Oho.

Step 2: Connect it in Oho​

In the left menu under Admin, open Data Sources, then start a new integration.

The Data Sources page in Oho

Pick Workday from the list of sources.

Choosing Workday as the source in Oho

Paste the ISU credentials, tenant, and endpoint from Step 1 into the connection fields and click Next.

Expected outcome: Oho confirms it can reach Workday and moves you on to field mapping.

Step 3: Map your fields​

Oho reads your Workday people and their records automatically, but Workday has its own names for things — its own organisations, qualification names, and status values — so the setup screen asks you to line each one up with its Oho value. For Workday, you map three things:

  • Organisations — your Workday companies → your Oho organisations, so each worker lands in the right place. Oho fetches workers one company at a time, so a company you don't map is never read at all.
  • Credentials — Workday's licence, certification, passport, visa and government-ID types → Oho credential types, so a record in Workday becomes something Oho can verify against the register. Each type is off until you map it.
  • Worker Status — Workday's employment-status values → Oho's ACTIVE, INACTIVE, ON_LEAVE, and TERMINATED, so active staff stay in your live reports and leavers drop out.

How Oho recognises a returning worker. For HRIS integrations like Workday, Oho matches on your upstream record ID, carried on source.externalId (the Workday Worker or Employee ID) — not on email. On each sync a match updates the existing person in place; no match creates a new one. You don't set this by hand; Oho reads it from Workday.

For what each field expects, which are required, how credentials tie to a worker, and how re-syncs avoid duplicates, see the shared Map your fields reference.

Anything you don't map is skipped, not imported

Unmapped means absent, not unplaced. A Workday company you leave out is never fetched, and a licence or certification type you leave out is read but discarded — neither shows up in Oho at all. Each run reports what it skipped and why, so a type that appears in Workday later surfaces in the run summary rather than slipping through silently.

Expected outcome: every Workday company, credential type, and status value you want in Oho maps to its Oho equivalent, and each worker carries their Workday Worker ID as the match key.

Step 4: Set the schedule​

Choose how often the sync runs, then name it and save.

  • Once — a one-off load to get started. Oho has your people after it runs; if the ISU was created just for this, you can retire it in Workday straight away.
  • Recurring — Oho re-reads Workday on a schedule, so new starters and changes there flow through automatically with nothing to re-enter. The ISU must stay valid for future runs, so keep it scoped read-only and rotate its credentials as above rather than retiring it.

Setting the sync schedule

Expected outcome: the connection is saved and scheduled, and it appears in your Data Sources list.

Step 5: Run & verify your first sync​

Run it now with Save & Run, or wait for the first scheduled run. Once it's run, confirm your people are in: they appear under All Workers, and each credential you listed is checked against its official source straight away (see One-off verification).

The new connection in your Data Sources list

If the run didn't bring everyone in, check the run history and the Common questions below.

Expected outcome: your people are in Oho under All Workers, with their credentials queued for verification.

What happens next​

  • Your people appear under All Workers, ready for checks.
  • To keep those checks current, add a verification source for the credential types you hold — synced credentials then verify at the register automatically.
  • You don't re-import by hand — change someone in Workday and Oho picks it up on the next scheduled run.

Common questions​

The sync found nothing. Check the ISU credentials are still valid and the tenant and endpoint are correct, and that the ISU's security group still grants access in Workday. Expired credentials or a revoked security group is the most common cause.

Some workers didn't import. Oho only reads the Workday companies you mapped in Step 3, so anyone in an unmapped company is never fetched. Check the mapping first, then confirm the affected people fall within the access granted to the ISU's security group.

Some credentials didn't import. Each credential type is off until mapped. The run summary names what it skipped — look for "Unmapped records skipped", which lists the counts by category. Add the missing type in Step 3 and re-run.

A permission error. The ISU can only read what its security group allows. If Oho is refused access to some people or fields, widen the security group to the read access Oho needs — no more.

The run says fields are missing for most workers. A warning like "Descriptive worker fields missing" counted against most of the workers parsed usually means Workday changed its schema or your tenant moved to a different web-services version — not that the data is blank. Contact support@weareoho.com so the field mapping can be re-checked against your tenant.

A leaver still shows as active. Oho re-fetches anyone it knows about who has dropped out of the response, reads their real termination date from Workday, and marks them inactive. If someone is still active after a run, check they haven't also been removed from the ISU's security group — Oho can't read a worker it has lost access to.

Can Oho change anything in Workday? No. The integration only reads. It calls a single operation, Get_Workers, and has no write path at all, so the ISU can safely be granted read-only access.

I don't see Integrations. This is an admin area — if it's not in your menu, ask an admin in your organisation, or contact support@weareoho.com.