Identity and access management
Workday to Omada integration: Workday as the authoritative source in Omada Identity
With an integration between Workday and Omada Identity, workers from Workday become identities in Omada, with supervisory organizations, locations, countries and job titles as context. Department, manager and end date from Workday thus drive roles and revoking access in Omada, and KoppelHet monitors the imports.
What the integration does
Organisations that use Workday as their global HR system and Omada for roles, requests and reviews often have the source set up during the Omada project, after which nobody looks at the connection again. Contingent workers then do not arrive as identities, an import with an expired token silently returns nothing, and reviews go to a former manager.
- In Workday we create an Integration System User with its own security group and read-only rights on the required domains.
- We register an API client with the Staffing and Organizations and Roles scopes and a non-expiring refresh token, for KoppelHet.
- KoppelHet delivers workers as identities and supervisory organizations, locations, countries and job titles as context to Omada.
- KoppelHet includes the key for contingent workers and the manager per organisation according to the Workday setup.
- KoppelHet monitors the imports and reports it if a delta stays empty while Workday does have changes.
What to watch for with Workday and Omada
- The API client in Workday must have non-expiring refresh tokens. If that is off, the integration stops as soon as the token expires. KoppelHet records that setting in the handover, so a security review in Workday does not silently reset it.
- The integration user's security group only needs view-only access, on four Staffing domains and four domains under Organizations and Roles. After adding them the policy change still has to be activated; without that step the integration gets empty responses.
- KoppelHet compares the number of changes in Workday with what Omada has imported, so a misconfigured date filter does not go unnoticed for weeks.
- Contingent workers have their own number in Workday. KoppelHet then takes the identity and the manager from Contingent_Worker_ID, so externals get the same reviews and revocation as permanent staff.
- A supervisory organization in Workday has a manager. KoppelHet delivers that manager as the context owner in Omada, so reviews go to the current manager.
- Get_Workers in Workday can leave out leavers: with Exclude_Inactive_Workers, terminated employees and contingent workers whose contract has ended drop out of the response. KoppelHet leaves that filter off, so the end date reaches Omada as ValidTo and access is revoked on time.
This integration is also part of joiner, mover, leaver.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Who decides the roles?
Omada. We make sure organisation, job title, manager and end date from Workday are right; the role rules live in Omada.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- To Omada through the REST collector: Workers as identities, Supervisory Organization, Location, Countries and Job title as context, with context assignment and managers as context owner. Workday API client with Staffing and Organizations and Roles scopes, Non-Expiring Refresh Tokens, client ID, secret and refresh token for the ISU.
- Security group of type Integration System Security Group (Unconstrained), View only on, among others, Worker Data: Public Worker Reports, Worker Data: Current Staffing Information, Worker Data: Workers, Worker Data: Organizations and Manage: Supervisory Organization.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Workday | Field in Omada | Notes |
|---|---|---|
Employee_ID of Contingent_Worker_ID | UID | Key of the identity |
Legal name | FirstName, LastName, Name | |
Job title | JobTitle | |
Worker status | Status | |
Hire date | ValidFrom | |
Termination date | ValidTo | |
Supervisory organization | Context | With the manager as context owner |
Work email | Email | |
Country, Company | Country, Company |
Related
Ashby → Workday
Ashby to Workday integration: hires to Workday, with a check on outcome and phone number
Bullhorn → Workday
Bullhorn to Workday integration: a consultant's first placement as a hire in Workday
Carerix → Workday
Carerix to Workday integration: a placed candidate becomes a pre-hire and starts the hire
Greenhouse → Workday
Greenhouse to Workday integration: hires as pre-hires, interim staff and contractors included