Identity and access management
Rippling to SailPoint integration: Rippling as the authoritative source in SailPoint Identity Security Cloud
With an integration between Rippling and SailPoint Identity Security Cloud, Rippling becomes the authoritative source, and every worker gets an identity with job title, department, entity, manager, employment type and a lifecycle that follows from the status in Rippling. SailPoint has no connector for Rippling, so KoppelHet delivers the data as a source in SailPoint and starts an aggregation after each change.
What the integration does
Organisations that use Rippling for HR and SailPoint for identity governance often have an export from Rippling as the source in SailPoint. Rippling also manages accounts in applications itself, so it is not always clear which access SailPoint granted and which Rippling did, and a rehire produces a second identity.
- Rippling gets an API token on an admin account, with read scopes only on workers, users, departments and changes.
- In SailPoint the administrator sets up a Delimited File source as authoritative source, with an identity profile and lifecycle states.
- Together with you we record which applications SailPoint manages and which Rippling manages.
- After each notification from Rippling KoppelHet delivers the file again, after which SailPoint starts an aggregation straight away.
- Every night KoppelHet compares all workers with the previous delivery and reports differences.
What to watch for with Rippling and SailPoint
- SailPoint Identity Security Cloud's connector lists include BambooHR and Personio, but not Rippling. Rippling describes no outbound provisioning to SailPoint. KoppelHet therefore delivers the data as a file to a Delimited File source, through the API that starts the aggregation straight away.
- Rippling also creates accounts in applications itself. SailPoint then sees accounts appear that were not requested or granted through SailPoint. Together with you we record per application who the owner is, so reviews in SailPoint are about real exceptions.
- A returning colleague gets a new worker under the same user in Rippling. SailPoint requires a uid that is unique across all identities. KoppelHet uses the user ID as uid, so the identity and its review history remain and only the dates and roles change.
- Rippling has the statuses INIT, HIRED, ACCEPTED, ACTIVE and TERMINATED. KoppelHet delivers the status together with start and end date, so a transform in SailPoint treats HIRED and ACCEPTED as pre-hire and TERMINATED after the end date as inactive.
- A termination in Rippling has a type, including offer declined and rescinded. KoppelHet delivers that type as an attribute, so SailPoint handles a hire that never started differently from a departure, and creates no review tasks for someone who never had access.
- Departments in Rippling have a parent department and a full hierarchy. Besides the department KoppelHet also delivers the path upwards, so roles in SailPoint can apply to a whole branch and do not have to be set per individual department.
- Rippling records when a change was saved and when it takes effect. KoppelHet holds a scheduled job or department change until the effective date, so SailPoint only grants new roles when the change actually takes effect.
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
Why a file and not a direct connection to Rippling?
SailPoint has no Rippling connector. With a Delimited File source through the API SailPoint gets the data right after a change, without manual work.
Can SailPoint then manage accounts in Entra ID or Okta itself?
Yes, with SailPoint's connectors. KoppelHet only supplies the HR source.
Does salary data go to SailPoint?
No. The token has no scope on compensation, and the file only contains 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 and department; status, start_date, end_date, termination_details.type, employment_type, legal_entity_id, department_hierarchy) and the Worker Changes API (applied_on and effective_on), plus webhooks. API token on an admin account with read scopes only.
- SailPoint Identity Security Cloud gets a Delimited File source as authoritative source; KoppelHet sends the file through the import accounts API, which starts the aggregation straight away. uid, email and lastname are required in every identity profile; uid unique across all identities. Lifecycle states through a transform on startDate, endDate and status.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Rippling | Field in SailPoint | Notes |
|---|---|---|
user_id | uid | |
work_email | email | |
Voornaam en achternaam | firstname en lastname | |
title | title | |
department.name en department_hierarchy | department en afdelingspad | |
legal_entity_id | company | |
manager (work_email) | manager | |
employment_type.type | workerType | |
status, start_date en end_date | startDate, endDate en status (lifecycle state) |
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