Identity and access management
Dayforce to Omada integration: Dayforce as the authoritative source for Omada Identity
With an integration between Dayforce and Omada Identity, every employee from Dayforce gets an identity in Omada, with department, location and manager of the primary work assignment, so roles and reviews run on HR data. Omada has no Dayforce connector and Dayforce delivers employees one at a time with a limit per minute; KoppelHet keeps the data current and prepares a complete list that Omada's REST collector reads in one go.
What the integration does
Organisations that use Dayforce for HR, payroll and time and Omada for identity governance sometimes try to point Omada's REST collector straight at Dayforce. That stops at the first full import, because Dayforce first returns only codes and a second call per employee, and refuses above one hundred per minute.
- In Dayforce we create a web services user with a role that may only read the organisation units and data for this integration.
- KoppelHet reads all employees once, spread within Dayforce's limit.
- After that KoppelHet only requests changed employees, plus hires and terminations with a future date.
- KoppelHet prepares one row per employee, which a REST system for identity data in Omada imports.
- After each import KoppelHet checks the counts and empty fields and reports deviations.
What to watch for with Dayforce and Omada
- Omada has no connector for Dayforce in the Connectivity Directory or the documentation. For such sources Omada describes the REST collector, and that is what we use here, with a list KoppelHet prepares rather than directly on the Dayforce API.
- Dayforce's list call only returns XRefCodes; the data itself comes per employee with a second call. In Omada that is only possible with a nested call per row, which Omada itself calls slower. Dayforce also allows only one hundred detail requests per minute. KoppelHet makes those requests spread out and keeps the result, so Omada reads one list.
- Dayforce itself reckons on about an hour for six thousand employees at one hundred per minute. Omada's REST collector waits 3600 seconds for a response by default. A direct full import of a large population therefore runs into the timeout; with the prepared list the import in Omada takes seconds.
- Dayforce's limit applies per client, shared by every application that uses the API. After the first fill KoppelHet only requests employees updated since the previous run, limited to work assignment, status and contact data, so a payroll or scheduling integration on the same Dayforce environment keeps capacity.
- According to Dayforce the list call applies no additional access control to the XRefCodes it returns. Codes of employees outside scope therefore come along. KoppelHet filters on the organisation units that belong in Omada, so Omada does not get identities from countries or companies that do not belong there.
- A hire is often recorded weeks ahead in Dayforce. KoppelHet requests the data as it applies on the start date and sets ValidFrom to that date, so Omada knows the future department and manager, but only lets roles start on the first working day.
- Dayforce stores managers per work assignment. Omada uses the owner of an identity and of a context for reviews. KoppelHet takes the manager of the primary work assignment as owner, so a review does not land with the manager of a second, small assignment.
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
Can Omada not read Dayforce itself?
Technically yes, with a nested call per employee. But with Dayforce's limit a full import then takes long and can fail on Omada's timeout.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Dayforce RESTful Web Services: GET /V1/Employees (XRefCodes only; filterUpdatedStartDate and filterUpdatedEndDate together, filterUpdatedEntities, filterHireStartDate, filterTerminationStartDate, orgUnitXRefCode) and per XRefCode the details with expand for WorkAssignments, EmploymentStatuses, EmployeeWorkAssignmentManagers and Contacts, with contextDate. Rate limiter: 10 per second or 100 per minute per client for Get Employee HR Details.
- Omada REST collector (Content: Identity data) with OAuth2 Client Credentials to the KoppelHet endpoint; paging with URL parameters; required identity mapping Business key, Unique ID, Name and Status; contexts with Business key, Name and Type, context assignments and identity owners; timeout 3600 seconds by default; thresholds per import.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Dayforce | Field in Omada | Notes |
|---|---|---|
XRefCode | Business key en Unique ID | |
FirstName, LastName, CommonName | Name, FirstName, LastName | |
Contacts (zakelijk e-mailadres) | Email | |
EmploymentStatuses | Status | |
HireDate en TerminationDate | ValidFrom, ValidTo | |
WorkAssignments (primair): Department | Context (afdeling) en context assignment | |
WorkAssignments (primair): Location | Context (locatie) | |
EmployeeWorkAssignmentManagers (primair) | Identity owner |
Related
Ashby → Dayforce
Ashby to Dayforce integration: have Dayforce validate the hire first, then save it
Bullhorn → Dayforce
Bullhorn to Dayforce integration: first placement of an employee as an employee in Dayforce
Carerix → Dayforce
Carerix to Dayforce integration: successful placement as a validated new employee in Dayforce
Dayforce → 4PS Construct
Dayforce to 4PS Construct integration: technicians and site managers from Dayforce in 4PS, with cost centre and end date