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. [Eng to confirm exactly how Oho authenticates to Workday — e.g. OAuth client-credentials for the ISU, or basic auth with the ISU username (isu@tenant) and password — and which fields Oho asks for in Step 2.]
  • Integration System User (ISU). Create a dedicated ISU for Oho rather than reusing a person's account, and set its password/token 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 granted the narrowest domain access that still lets Oho read workers and job history — read-only. [Eng to confirm the exact domain security policies / web-service operations required — e.g. the RaaS report, WQL, or Human Resources / Staffing web services Oho calls.]
  • Tenant & endpoint. [Eng to confirm precisely what Oho needs — e.g. the tenant name and the web-services (WWS) or REST API endpoint URL — and where the admin finds it in Workday.]
  • Credential storage. The ISU credentials are stored encrypted in Oho and sent on each request. [Eng to confirm any IP allow-list requirement on the Workday side.]
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, click Integrations, then start a new integration.

The Integrations page in Oho

Pick Workday from the list of sources.

Choosing Workday as the source

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

Entering the Workday connection details in Oho

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 organisations, companies, or supervisory organisations → your Oho organisations, so each worker lands in the right place.
  • Qualifications — Workday qualification and certification names → Oho credential types, so a qualification in Workday becomes something Oho can verify against the register.
  • 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.

Map every value, or those rows won't land where you expect

A Workday organisation or qualification you leave unmapped still imports as a record, but Oho can't place it or verify it until it's mapped. If a new organisation or qualification appears in Workday later, Oho flags it so you can map it rather than letting it slip through.

Expected outcome: every Workday organisation, qualification, and status value 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 Integrations 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 Workday connection in your Integrations list, run history green

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. Check your field mapping in Step 3 — an unmapped organisation or status can leave people out of the reports you expect. Confirm the affected people fall within the access granted to the ISU's security group.

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.

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.