HR to ITSM
Rippling to TOPdesk integration: persons, branches and tickets from Rippling's change feed
With an integration between Rippling and TOPdesk, every worker from Rippling is a person in TOPdesk, with department, branch and manager, and every hire, change and offboarding creates an incident or change for the right operator group. KoppelHet reads Rippling's change feed, so even a move that only takes effect next month reaches the service desk on time.
What the integration does
Organisations that manage HR, devices and spend in Rippling and run a Dutch service desk in TOPdesk find that TOPdesk lags behind. Without an integration a new colleague with a signed offer sits in Rippling for weeks before anyone emails the service desk, and a withdrawn offer sometimes still results in an ordered laptop.
- HR creates the new worker in Rippling; they go through the offer and are hired.
- KoppelHet sees the hire in the change feed, fetches the worker and creates the person in TOPdesk with department, branch and manager.
- Within the agreed lead time before the start date an onboarding incident or a change from your template is created, in the new colleague's name.
- A different department, job or manager results in a change ticket, on the effective date Rippling provides.
- A scheduled offboarding gives an offboarding ticket a week before the last working day. After that day KoppelHet archives the person.
What to watch for with Rippling and TOPdesk
- Rippling records two moments for every change, when it was saved and when it takes effect. KoppelHet requests changes by the moment they were saved. The service desk thus also sees a promotion or department change that only takes effect next month, while the person in TOPdesk only changes on the effective date.
- A worker ID in Rippling is a long string of letters and digits, while TOPdesk allows at most 20 characters in the employee number. KoppelHet therefore puts Rippling's worker number in the employee number and keeps the ID in a free field.
- Rippling has its own termination type for an offer that is declined or withdrawn before the start. KoppelHet then puts the open onboarding ticket in TOPdesk on hold with a note, so no laptop is shipped to someone who is not coming.
- A worker in Rippling works at a work location or remotely. For remote workers there is no address to make a branch from. KoppelHet assigns those colleagues to a branch per country, so the onboarding change shows which team ships the laptop.
- Rippling can undo a change with its own event type. If a department change is reversed, KoppelHet restores the person in TOPdesk and does not create a second change ticket.
- Fields the integration has no read access to in Rippling come back as redacted, without a value. KoppelHet therefore sees a salary change as an event but never its content, and such a change causes nothing in TOPdesk.
- Rippling only sends employee notifications to apps in its own App Shop. For a customer integration KoppelHet therefore requests the change feed every few minutes, and compares all active workers with TOPdesk daily, so a missed change does not linger.
- Rippling distinguishes employees and contractors. The type of relationship goes to TOPdesk, so a contractor with their own laptop gets an onboarding ticket for accounts and access only.
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
Rippling manages devices itself. Why TOPdesk as well?
If facilities and IT work in TOPdesk, the work belongs there. The integration makes sure TOPdesk knows the same people as Rippling. Which system manages the devices is agreed at the start.
Do we need a special Rippling subscription?
The API requires Rippling's API SKU, and the change feed needs a separate entitlement arranged by your Technical Account Manager. We check this in the intake.
Do all countries go into TOPdesk?
Only the workers this service desk serves, for example the Dutch office and those working remotely from the Netherlands. The integration ignores the rest.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Rippling is read through the v2 REST API at rest.ripplingapis.com with an API token with read-only scopes (workers.read, worker-changes.read). GET /worker-changes/ filtered on applied_on, with event_type HIRE, CHANGE, SCHEDULED_CHANGE, OFFBOARD, SCHEDULED_OFFBOARD, UNDO and EFFECTIVE_DATE_AMENDMENT and per change field_key, from_value and to_value (REDACTED without read access). The Worker Changes API requires the Rippling API SKU and an entitlement through the Technical Account Manager.
- Workers through GET /workers with expand on user, manager, department and employment_type (at most 100 per page, cursor). Fields include number, work_email, title, status (INIT, HIRED, ACCEPTED, ACTIVE, TERMINATED), start_date, end_date, location (REMOTE or WORK with work_location_id), employment_type (EMPLOYEE or CONTRACTOR) and termination_details.type (including OFFER_DECLINED, RESCIND and RENEGE). Version pinned through the Rippling-Api-Version header.
- TOPdesk is written through the TOPdesk REST API with an operator's application password: persons and branches through Supporting Files (employeeNumber at most 20 characters, archiving with a reason), incidents with POST /tas/api/incidents (callerLookup, briefDescription, request, operatorGroup, targetDate, externalNumber) or changes with POST /tas/api/operatorChanges from a template (template, requester). KoppelHet stores per worker which ticket already exists, per hire and per end date.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Rippling | Field in TOPdesk | Notes |
|---|---|---|
number (workernummer) | employeeNumber | The Rippling ID itself is too long for this field |
id (worker) | Vrij veld bij de persoon | Fixed key for lookups |
Voornaam en achternaam (user) | firstName en surName | |
work_email | email | |
title | jobTitle | |
department | department | |
location (WORK met work_location_id, of REMOTE) | branch | A work location becomes a branch; remote to a branch per country |
manager_id | manager | |
employment_type (EMPLOYEE of CONTRACTOR) | Vrij veld soort arbeidsrelatie | |
start_date en end_date | hireDate en employmentTerminationDate (contract) | |
HIRE, CHANGE of SCHEDULED_OFFBOARD | Melding (incidents) of wijziging uit sjabloon (operatorChanges) | |
Gesynchroniseerde persoon | callerLookup of requester | The ticket is in the worker's name |
effective_on van de wijziging | targetDate en briefDescription |
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