Identity and access management
Deel to Ping Identity integration: PingOne users for employees, EOR and contractors from Deel
With an integration between Deel and Ping Identity, everyone working for you through Deel gets a user in PingOne, in a population that fits the type of work relationship, with entity, department and manager. After the last day in Deel that user can no longer sign in; because Deel does not deliver to identity providers itself, KoppelHet writes directly through PingOne's APIs.
What the integration does
Organisations that have employees, EOR staff and contractors in several countries through Deel and use PingOne for access often create PingOne users based on a notification from Deel. The end of a contractor's contract then does not always reach IT, so accounts keep working.
- Deel gets an organisation token with read rights only on people and contracts; PingOne gets a Worker app with the Identity Data Admin role.
- Together with you we set up a population for own employees and EOR, and one for contractors.
- For a new person in Deel KoppelHet creates the PingOne user with sign-in blocked until the start date.
- Entity and department become groups; a move to another type of work relationship moves the user to the other population.
- After the last day KoppelHet blocks sign-in; deletion only follows after the retention period.
What to watch for with Deel and Ping Identity
- Deel writes that direct provisioning to identity providers is not supported and that a middle layer fetches and passes on the people. PingOne only has a ready-made HR provisioner for Workday. KoppelHet is that middle layer and fills PingOne through Ping's user API.
- PingOne puts every user in exactly one population. KoppelHet picks it from the type of work relationship in Deel, so contractors get their own population with, for example, stricter MFA or shorter sessions than own employees and EOR staff.
- If a contractor becomes an employee or EOR, Deel creates a new contract. KoppelHet keeps the person's Deel ID as externalId and moves the user with PingOne's separate population request, so MFA devices and history remain and no second user is created.
- Someone who has not started in Deel is NOT_STARTED. KoppelHet then already creates the PingOne user with sign-in blocked, so laptop and apps can be prepared, and enables sign-in on the start date.
- Deel advises deactivating on departure rather than deleting, because deletion cannot be undone. KoppelHet blocks sign-in in PingOne on the last day and only deletes after the retention period, so a contract that is extended after all keeps the same user.
- Deel gives the manager as a work email, and PingOne has no standard field for the manager. KoppelHet puts the manager's address in a custom attribute in the user schema, so approvals in PingOne flows reach the right person.
- Deel pauses notifications to an address after ten failed attempts, and advises a full sync as a safety net next to notifications. KoppelHet monitors the notifications and compares all people with PingOne every night, so a missed departure leads to a block by the next morning at the latest.
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 contractors also get a PingOne user?
Yes, in their own population. You decide in PingOne which policy applies there.
What happens to administrators and service users in PingOne?
The integration leaves them alone. KoppelHet only touches users with a Deel ID.
Does payment data go to PingOne?
No. The token has no rights on payments.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Deel through the HRIS People API and contracts (worker_id, hiring_type, person_status ACTIVE, NOT_STARTED or INACTIVE, client_legal_entity, termination_last_day, direct_manager.work_email) with an organisation token, plus webhooks signed with x-deel-signature, idempotent on event_id. Deel's SCIM API (GET /scim/Users, Users:read) as a check.
- PingOne with a Worker app (Identity Data Admin): users through /v1/environments/{envID}/users or the SCIM entry point, username unique and at most 128 characters, population.id only changeable through the population sub-resource, groups through the Platform API, custom attributes in the user schema and sign-in blocked through enabled.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Deel | Field in Ping Identity | Notes |
|---|---|---|
worker_id | externalId | |
Voornaam | name.given | |
Achternaam | name.family | |
Naamgevingsregel | username en email | |
hiring_type | population.id | |
client_legal_entity | Groep per entiteit | |
department | Groep per afdeling | |
direct_manager.work_email | Eigen attribuut leidinggevende | |
person_status en termination_last_day | enabled |
Related
Ashby → Deel
Ashby to Deel integration: hires at the own entity as direct employee in Deel
Bullhorn → Deel
Bullhorn to Deel integration: first placement as a direct employee with a contract in Deel
Carerix → Deel
Carerix to Deel integration: successful placement as a person or contract in Deel
Deel → 4PS Construct
Deel to 4PS Construct integration: own employees of the construction entity in 4PS, with department and cost centre as dimensions