Identity and access management
Remote to Omada integration: employees, EOR and contractors from Remote as identities in Omada
With an integration between Remote and Omada Identity, everyone who works for you through Remote is an identity in Omada, with employment type, entity, country, department and manager, and with a status that follows onboarding and offboarding in Remote. Omada has no connector for Remote; KoppelHet delivers the identities to Omada's REST collector.
What the integration does
Organisations that employ people in other countries through Remote and use Omada for identity governance often do not see those people in their HR source for Omada. Accounts of EOR employees and contractors then hang in Omada without an identity, and fall outside reviews and departure rules.
- Remote gets a Customer API token with read scopes only, and webhooks for employment and user status.
- KoppelHet keeps one row per employment with the status according to your agreements.
- In Omada the administrator creates a system with the REST collector for identity data, with OAuth2 Client Credentials to KoppelHet.
- Omada reads identities, contexts and owners, and calculates roles per employment type and entity.
- At go-live we set a threshold on deleted identities.
What to watch for with Remote and Omada
- Remote offers employees through a SCIM endpoint, and Omada has a SCIM collector. That collector, however, reads users as accounts, not identities, and since Omada 14.0.7 only puts a list in an extension attribute. KoppelHet therefore delivers Remote to the REST collector, with identities, contexts and owners.
- An employment in Remote goes through many steps before active, such as invited, onboarding started, in review and waiting for missing fields. KoppelHet delivers all those steps as inactive, so Omada can prepare rights but only grants them once Remote sets the employment to active.
- Remote sets the user status to inactive when an employment is suspended, and sends a separate webhook for it. KoppelHet delivers such a person as inactive and not as terminated, so Omada pauses access without starting the departure procedure.
- Remote has four employment types, including EOR through Remote, contractor and direct_employee for your own entity. KoppelHet delivers the type as a context, next to the entity that employs someone, so Omada can use different roles and reviewers for a contractor than for an employee.
- On an offboarding Remote first checks the country's rules, after which the end date can still move. KoppelHet only sets the identity's validity once Remote has processed the offboarding, so Omada does not revoke access on a proposed date.
- Confidential offboardings are not in Remote's normal list and only come along when you ask for them separately. KoppelHet requests them separately and gives Omada only the end date and status, without a reason, so reviewers in Omada see nothing about the departure.
- Remote lets an administrator soft-delete an employment. KoppelHet does not treat that as a departure but reports it to HR, and keeps a threshold on deleted identities in Omada, so a clean-up in Remote does not silently make identities disappear.
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
Can Omada not read Remote's SCIM endpoint itself?
As accounts, yes, but not as identities with status and contexts. For identity governance the REST collector with KoppelHet is the route.
Do EOR employees and contractors also reach Omada?
Yes, with the employment type as a context, so you can attach your own rules to it.
Does Omada see the reason for a departure?
No. Omada only gets status and end date.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- KoppelHet reads Remote through the Remote API (gateway.remote.com) with a Customer API token: GET /v1/employments (status created to active, archived and deleted; type; engaged_by_legal_entity_id), SCIM GET /v1/scim/v2/Users for department, employee number and manager, webhooks signed with X-Remote-Signature (including employment.user_status.activated and employment.user_status.deactivated) and confidential offboardings with include_confidential.
- 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 and identity owners. Thresholds for new, modified and deleted objects. Omada's SCIM collector imports users as accounts.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Remote | Field in Omada | Notes |
|---|---|---|
employment id | Business key en Unique ID | |
Naam | Name | |
status en user_status | Status | |
type (employee, contractor, direct_employee, global_payroll_employee) | Context (type soort dienstverband) | |
engaged_by_legal_entity_id en country | Context (type entiteit) | |
department (SCIM enterprise extension) | Context (type afdeling) | |
manager (SCIM enterprise extension) | Owner UID | |
Bevestigde einddatum offboarding | Geldig tot |
Related
Greenhouse → Remote
Greenhouse to Remote integration: foreign hires as EOR employment with the country's form
Recruitee → Remote
Recruitee to Remote integration: hires abroad straight into an employment at Remote
Remote → 4PS Construct
Remote to 4PS Construct integration: own employees of the construction entity from Remote in 4PS
Remote → Active Directory
Remote to Active Directory integration: accounts for colleagues in other countries