Identity and access management
Workday to OneLogin integration: Workday as a directory in OneLogin, with OneLogin's connectors
With an integration between Workday and OneLogin, every new hire from Workday gets a OneLogin user with department, job title and roles, and a leaver loses access to all apps behind OneLogin after the end date. OneLogin offers two Workday directories for this itself; KoppelHet sets them up, handles the status on joining and leaving and fills in where the connectors stop.
What the integration does
Organisations with Workday as their HR system and OneLogin for single sign-on often switch on OneLogin's Workday directory quickly, but leave the rules for status and departure open. New users then sit in OneLogin without a status, and a leaver keeps access because no mapping reacts to the Workday status.
- In Workday we create an Integration System User with its own security group and a report with all workers, available as a web service.
- In OneLogin we create a directory of type Workday Custom Reports with the JSON and XSD addresses of that report.
- KoppelHet maps the report fields to OneLogin fields and creates the custom fields OneLogin needs for them.
- Mappings in OneLogin set a new user to active and assign roles based on department and job title.
- A mapping on the Workday status shuts out a leaver, and KoppelHet checks on the end date that this actually happened.
What to watch for with Workday and OneLogin
- OneLogin has two Workday directories. Workday Custom Reports reads a report as a web service; the Workday Bidirectional directory uses the Get_Workers web service and also writes back. OneLogin itself advises importing users through the report and using the bidirectional variant only for writing back.
- A user who arrives in OneLogin through the Workday directory gets no status by default. OneLogin advises a mapping that sets the status to active on creation. Without that mapping a new colleague cannot sign in on the first day.
- For departures OneLogin describes a mapping on Workday Status equal to Terminated, but not that the OneLogin user is disabled by it. KoppelHet sets up that mapping and checks on the end date that the user really has no access anymore.
- According to OneLogin the Workday report must contain at least first name, last name, employee ID and username. Every extra field OneLogin needs to see, such as department or worker type, we first add to the report and then as a custom field in OneLogin.
- Writing back to Workday is possible for work email, work and home phone, office address and messaging details, not for education data. For that the integration user needs both Get and Put rights, and its security group must be in the Maintain Contact Information (Web Service) policy.
- If a worker is in the middle of a business process, a normal contact change fails. OneLogin has the Use Change Contact API option for that, which needs at least Workday version 30. KoppelHet switches it on, so the new work email also reaches Workday during an ongoing hire.
- In OneLogin the manager is a OneLogin user ID, not a Workday number. On every change KoppelHet first looks up the manager's OneLogin user, so approvals in apps behind OneLogin reach the right person.
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
OneLogin already has a Workday directory. What does KoppelHet do then?
Setting up the Workday report and the integration user, building the mappings for status, roles and departure, and checking that a leaver really has no access on the end date.
Which variant of the Workday directory do we use?
Custom Reports to import employees, as OneLogin recommends. The bidirectional variant only if the work email or phone needs to go back to Workday.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- OneLogin Workday Custom Reports directory: Workday report (for example All Workers, Advanced, Enable as a Web Service) through https://<tenant>.workday.com/ccx/service/customreport2/<tenant>/<report>?format=json and ?xsd; mapping on the Directory Attributes page; first load with Synchronize Users (Force).
- OneLogin Workday Bidirectional directory: Get_Workers for the schema, Update Contact and Change Work Contact Information (Web Service) for writing back; API user as username@tenant; Integration System Security Group (Unconstrained) with Get on Worker Data: Public Worker Reports and Get and Put on the contact domains; required mappings worker_id to external_id, primary_work_email to email and user_id to username.
- KoppelHet checks the status of users on the end date through the OneLogin API v2 (OAuth 2.0 client credentials) and looks up manager_user_id.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Workday | Field in OneLogin | Notes |
|---|---|---|
Employee ID (worker_id) | external_id | Fixed key, also after a name change |
Legal First Name, Legal Last Name | firstname, lastname | |
Primary Work Email | email | |
User Name (user_id) | username | |
Business Title | title | |
Supervisory Organization | department | Basis for roles through mappings |
Manager | manager_user_id | OneLogin ID of the manager, not an employee number |
Worker Status | status (via mapping) |
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