Identity and access management
Rippling to Omada integration: identities, entities and departments from Rippling in Omada Identity
With an integration between Rippling and Omada Identity, Omada reads every employee and contractor from Rippling as an identity, with entity, department, manager and a status that follows from start, departure or a withdrawn hire. KoppelHet delivers the data to Omada's REST collector.
What the integration does
Organisations that use Rippling for HR and Omada for identity governance often update employees and contractors in Omada with an export or by hand, and entities through PEO or EOR fall outside the policies in Omada.
- Rippling gets an API token on an admin account with read scopes only on workers, users, departments and entities.
- KoppelHet keeps one row per person with the status according to your agreements, and a context per entity and department.
- In Omada the administrator creates a system with the REST collector for identity data, with OAuth2 Client Credentials to KoppelHet.
- Omada reads identities, contexts, assignments and owners and calculates roles and access.
- At go-live we set thresholds for new and deleted identities.
What to watch for with Rippling and Omada
- KoppelHet offers Omada one address with identities, contexts and owners in the form the collector expects.
- A legal entity in Rippling can run through PEO, EOR or COR. KoppelHet delivers each entity as a context in Omada and includes that arrangement in the type, so in Omada you can set different policies or reviewers for people through EOR than for your own company.
- Rippling creates a new worker under the same user on a rehire. KoppelHet uses the user ID as business key, so Omada reactivates the existing identity with its earlier attestations instead of creating a second identity.
- A context in Omada has its own business key. KoppelHet uses the department's ID in Rippling and not its name, so a renamed department remains the same context in Omada and roles stay attached to it.
- Rippling ends a hire that does not go ahead with its own type, such as offer declined or rescinded. KoppelHet delivers such a person as terminated without ever having been active, so Omada starts no departure procedure or review for someone who never got access.
- Omada warns that a status from an HR source can overwrite status changes in Omada, such as a block by security. Together with you we decide whether Rippling or Omada leads for the status, and set up the mapping in Omada accordingly.
- A Rippling API token expires when it has not been used for thirty days or when its creator leaves. KoppelHet then passes the error through the error path the REST collector reads, so Omada marks the import as failed instead of seeing everyone as gone.
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 reach Omada?
Yes. The worker type from Rippling goes along, so Omada can give contractors different roles and reviews.
Does Omada read pay data from Rippling?
No. KoppelHet's token has no scopes on compensation, and Omada only sees the fields from the design.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- KoppelHet reads Rippling through the REST API (rest.ripplingapis.com: /workers with expand user, manager, department and legal_entity; status INIT, HIRED, ACCEPTED, ACTIVE or TERMINATED, termination_details.type, employment_type.type, legal_entity.management_type PEO, EOR or COR) and webhooks. API token on an admin account with read scopes only.
- Omada reads through the REST collector (Content: Identity data) with OAuth2 Client Credentials: identities with Business key, Unique ID, Name and Status; contexts with Business key, Name and Type; context assignments; identity owners with Owner UID. Paging through Link header; Error message JSON path; thresholds for new, modified and deleted objects (default 0, off).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Rippling | Field in Omada | Notes |
|---|---|---|
user_id | Business key en Unique ID | |
Voornaam en achternaam | Name | |
status, start_date, end_date en termination_details.type | Status | |
legal_entity_id met management_type | Context (type entiteit) | |
department_id | Context (type afdeling) | |
manager_id (via user) | Owner UID | |
employment_type.type | Extensieattribuut soort medewerker | |
title | Extensieattribuut functie |
Related
Carerix → Rippling
Carerix to Rippling integration: successful match as a hire for review in Rippling
Greenhouse → Rippling
Greenhouse to Rippling integration: every hire straight into Rippling for review
Recruitee → Rippling
Recruitee to Rippling integration: hired candidates ready to hire
Rippling → 4PS Construct
Rippling to 4PS Construct integration: own employees of the construction entity in 4PS, with department as a dimension