Identity and access management
Officient to Okta integration: Okta users from Exact Officient, with language and manager
With an integration between Officient and Okta, every new person in Exact Officient gets an Okta user with team, role, manager and preferred language, and Okta deactivates that user after the last day of the employment. KoppelHet does this based on Officient's webhooks.
What the integration does
Organisations that use Exact Officient for HR and payroll and Okta as their identity provider often enter new colleagues in Okta by hand. A leaver in Officient then only reaches Okta if someone remembers.
- In Officient we create a client app for KoppelHet with read rights on personal information only, and register the webhooks.
- In Okta the account team enables a custom HR source for KoppelHet.
- On a notification KoppelHet fetches the person's details and delivers the change to Okta.
- Team and role decide the Okta groups, and with that the apps.
- After the last day of the employment Okta deactivates the user; on a reactivation they become active again.
What to watch for with Officient and Okta
- KoppelHet fills Okta from Officient, so the employee exists in Okta before they first sign in.
- Officient has separate webhooks for a different role, a different team and a new manager, and the body only contains the person's ID. KoppelHet fetches the details on every notification and only delivers the changed part to Okta, so a team change updates the Okta group within minutes.
- Officient stores the preferred language as a two-letter code, such as nl or fr. Okta's standard profile has preferredLanguage and locale. KoppelHet puts the code there, so the Okta dashboard and Okta emails appear in French for a French-speaking colleague.
- Besides the regular manager Officient has an extra manager. Okta's standard profile has only one managerId. KoppelHet puts the regular manager in managerId and the extra manager in a custom attribute, so Okta Workflows can use both for approvals.
- With person_reactivated Officient reports that someone is coming back. KoppelHet finds the deactivated Okta user through the Officient ID and makes them active again, instead of creating a second user with a new address.
- If HR deletes a person in Officient, person_deleted follows. KoppelHet deactivates the Okta user on that notification and does not delete, so the assignments and the log in Okta are kept until IT decides.
- Officient only fills the payroll provider number for some of the Dutch integrations. KoppelHet therefore uses Officient's own ID as the key in Okta, which always exists for Belgian employees too.
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
What if a new person has no work email yet?
Then KoppelHet builds the Okta login with the agreed naming rule.
Does the integration read salaries in Officient?
No. The client app only has read rights on personal information.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Officient REST API (api.officient.io/1.0) with a bearer token from a dedicated client app (scope personal.info:read): GET /people/{id}/detail with email, team, current_role, current_reports_to (person_id, extra_manager_id), employment (first_employment_date, last_employment_date) and preferred_language_code. Webhooks person_added, person_updated, person_deleted, person_reactivated, person_team_updated, person_manager_updated and person_role_updated; resent on any status other than 200; at most 30 calls per 5 seconds.
- Okta through a Custom Identity Source (bulk upsert of up to 200 profiles per request, string values only, bulk delete deactivates) or through the Users API with an OAuth 2.0 service app (lifecycle activate, deactivate, reactivate). Sign-in to Officient's self-service app through a SAML app in Okta.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Officient | Field in Okta | Notes |
|---|---|---|
id (Officient) | externalId en employeeNumber | |
Voornaam en achternaam | firstName en lastName | |
email of naamgevingsregel | login en email | |
team | department en groep per team | |
current_role | title | |
current_reports_to.person_id | managerId | |
current_reports_to.extra_manager_id | Eigen attribuut tweede leidinggevende | |
preferred_language_code | preferredLanguage en locale | |
employment.last_employment_date | Deactiveren |
Related
Officient → Active Directory
Officient to Active Directory integration: AD accounts from Exact Officient
Officient → ADP iHCM
Officient to ADP iHCM integration: Dutch wages and leavers from Exact Officient to ADP iHCM
Officient → AFAS Profit
Officient to AFAS integration: Dutch employees from Exact Officient in AFAS Profit Payroll
ASOfficient → Arbodienst (SIVI)
Officient to the occupational health service via SIVI: absence periods from Exact Officient as absence reports