Identity and access management
Dayforce to Ping Identity integration: Dayforce as the source for users in PingOne
With an integration between Dayforce and Ping Identity, every new employee from Dayforce gets a user in PingOne, in the population of their country and with job title, department and manager from the primary work assignment. PingOne does not import Dayforce itself; KoppelHet delivers the users through PingOne's SCIM entry point, within the limit of the Dayforce API, and disables them on the end date.
What the integration does
Organisations that use Dayforce for HR and payroll and PingOne as their access gateway discover that PingOne only knows Workday as an HR source. New colleagues then reach PingOne through a form from HR, and because Dayforce often serves several countries, everyone ends up in one population with the same policy.
- In Dayforce we create a web services user with a role that may only read the required organisation units and data.
- In PingOne the administrator creates a Worker app with the Identity Data Admin role and a population per country.
- KoppelHet requests the changed employees and reads the details per employee, spread within Dayforce's limit.
- A new employee becomes a disabled user in their country's population; on the start date KoppelHet enables them.
- On the end date KoppelHet disables the user, and every day KoppelHet checks per employee whether PingOne matches.
What to watch for with Dayforce and Ping Identity
- PingOne only knows Workday as an inbound HR source, next to an LDAP gateway and SCIM. Advanced Identity Cloud has no Dayforce template either. KoppelHet therefore delivers through the SCIM API, which Ping itself recommends for importing users.
- There is a limit on both sides. Dayforce gives at most one hundred employee details per minute per client, and PingOne returns at most two hundred users through SCIM without a next page. KoppelHet therefore does not compare with full lists, but per employee on externalId, spread over the night.
- Dayforce often serves several countries, and the work location of the primary assignment determines the country. KoppelHet puts each user in that country's PingOne population, so password policy and MFA can differ per country. If someone moves to another country, KoppelHet moves the user with PingOne's separate population call.
- A hire is often recorded weeks ahead in Dayforce, and PingOne enables a new user by default. KoppelHet requests the data as it applies on the start date and explicitly creates the user disabled. On the start date it is enabled, with the job and country of the new role.
- Dayforce can record an account for single sign-on per employee. If employees sign in to Dayforce through PingOne, KoppelHet puts the PingOne username there. Because that name is fixed in PingOne once PingID is in use, the SSO account in Dayforce does not change on a name change.
- Dayforce stores a common name next to the official name. PingOne has a nickname next to given and family name. KoppelHet puts the common name there, so PingOne's welcome screen shows the name the colleague uses.
- Fields only come along in Dayforce if the API user's role has rights to them, without an error if not. A user without a country would end up in PingOne's default population. KoppelHet holds back an employee without country or job and reports it to HR.
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
Do other Dayforce integrations notice this?
Dayforce's limit applies per client. KoppelHet only requests changes and spreads the daily check, so other integrations keep capacity.
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 with filterUpdatedStartDate and filterUpdatedEndDate, filterHireStartDate, filterTerminationStartDate and orgUnitXRefCode (XRefCodes only, without additional access control), then per XRefCode the details with expand for WorkAssignments, EmploymentStatuses, EmployeeWorkAssignmentManagers, Contacts and SSOAccounts, with contextDate. Rate limiter 10 per second or 100 per minute per client.
- PingOne through a Worker app with the Identity Data Admin role: SCIM /v2/Users with externalId, userName (unique, at most 128 characters, fixed with PingID), one email value, nickName, title, active and population.id in the PingOneUser extension; searching on externalId; lists up to 200 without paging; changing population through PUT /users/{id}/population.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Dayforce | Field in Ping Identity | Notes |
|---|---|---|
XRefCode | externalId | |
FirstName, LastName | name.givenName, name.familyName | |
CommonName | nickName | |
Contacts (zakelijk e-mailadres) of naamgevingsregel | userName en emails (één waarde) | |
WorkAssignments (primair): Job | title | |
WorkAssignments (primair): Location, land | population.id | |
EmployeeWorkAssignmentManagers (primair) | Manager (eigen attribuut) | |
EmploymentStatuses en TerminationDate | active (enabled) | |
userName (PingOne) | SSOAccounts (Dayforce) |
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