Identity and access management
Unit4 HR to Omada integration: identities and contexts from Unit4 ERPx in Omada Identity
With an integration between Unit4 HR and Omada Identity, Omada reads every approved employee from Unit4 ERPx as an identity, with company, organisational unit and cost centre as contexts and a status that follows from the employment. KoppelHet offers Omada's REST collector one flat record per employee, with the values that apply on the day of the import.
What the integration does
Organisations that run HR and finance together in Unit4 ERPx and govern access with Omada Identity often lack the right department and cost centre in Omada. A transfer that HR enters in advance changes roles too early, and a second employment grants rights nobody assigned on purpose.
- Unit4 Identity Services gets a machine client for KoppelHet, and Omada gets its own client credentials for KoppelHet's address.
- KoppelHet fetches the changed employees with their employments and relations and keeps a full state.
- Per employee KoppelHet prepares one record with the main employment and the relations that apply that day.
- Omada reads identities, contexts and context assignments through the REST collector and processes them in the data warehouse.
- Roles and approvals in Omada follow the contexts; on termination Omada revokes access according to your policy.
What to watch for with Unit4 HR and Omada
- Unit4 and Omada's REST collector both work with OAuth2 client credentials, so Omada could in principle call Unit4 itself. In Unit4, however, a machine client only gets rights through a user with the SUPER or SYSTEM role, which can also reach financial data. That key stays with KoppelHet; Omada only reads the identity fields.
- Omada's REST collector can follow nested data, but then only takes the first element of a list. In Unit4 an employee has a list of employments and relations. KoppelHet selects the main employment and the valid relations beforehand, so Omada does not use a random job as a basis for roles.
- Organisational unit and cost centre hang in Unit4 as relations with a date from and to. KoppelHet only delivers the context assignment from the effective date, so Omada does not grant roles of the new department on the day HR enters the transfer.
- Besides identities, Omada can also read contexts with a type. KoppelHet makes each Unit4 company, organisational unit and cost centre its own context, so ownership and certification in Omada follow the same lines as the budget in Unit4.
- A personId in Unit4 is only unique within a company; Unit4 rejects a duplicate number in the same company with a conflict. Omada requires a unique business key. KoppelHet puts the company in front of the person number, so employees of two companies in one tenant never end up as one identity.
- A new employee can first be in an approval workflow in Unit4; Unit4 reports that with a separate status. KoppelHet only includes them in the records for Omada once the workflow is complete, so no request process starts in Omada for someone HR still rejects.
- Terminating sets the employee's status in Unit4 to Terminate. Omada keeps its own status events and warns that an HR status can overwrite those changes. We agree beforehand whether the Unit4 status or Omada leads, and KoppelHet only delivers the status that goes with that.
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 does Omada not read Unit4 directly?
It is technically possible, but requires a Unit4 key with broad rights and logic for dates and multiple employments. KoppelHet keeps those outside Omada.
What happens to a second employment?
By default only the main employment counts. An extra context assignment per second employment can be added later as an extension.
Does financial or pay data go to Omada?
No. Only name, status, company, unit, cost centre and job title.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Unit4 ERPx through the employees API and the ObjectAPI with OAuth 2.0 client credentials via Unit4 Identity Services (scope u4erp, M2M user with SUPER or SYSTEM role, at most ten per tenant). Fields include companyId, personId, personnelType, status, nameInformation (firstName, surname, aliasName), employments and relatedValues with dateFrom and dateTo; incremental on lastUpdated; 202 for an entry in workflow; DELETE sets the status to Terminate.
- Omada reads through the REST collector with OAuth2 Client Credentials: identities (Business key, Unique ID, Name, Status), contexts (Business key, Name, Type) and context assignments (Context business key, Identity UID). Thresholds for new, modified and deleted objects are 0 (off) by default; we switch on the threshold for deleted objects.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Unit4 HR | Field in Omada | Notes |
|---|---|---|
companyId + personId | Business key en Unique ID | personId is unique within a company |
nameInformation (aliasName of firstName, surname) | Name | |
status en einddatum hoofddienstverband | Status | |
Bedrijf | Context (type bedrijf) | |
Organisatie-eenheid (relatie op datum) | Context (type afdeling) en contexttoewijzing | |
Kostenplaats (relatie op datum) | Context (type kostenplaats) en contexttoewijzing | |
Functie van het hoofddienstverband | Identiteitsattribuut functie |
Related
Greenhouse → Unit4 HR
Greenhouse to Unit4 HR integration: accepted offer as an employee in the right Unit4 company
Recruitee → Unit4 HR
Recruitee to Unit4 HR integration: hired candidate as employee in Unit4, validated before it is saved
SmartRecruiters → Unit4 HR
SmartRecruiters to Unit4 HR integration: hire on the position from SmartRecruiters, with onboarding status back
Teamtailor → Unit4 HR
Teamtailor to Unit4 HR integration: hired candidates as employees in Unit4 ERPx, with company and position