Identity and access management
Simployer to Okta integration: Okta users from Simployer One, with Simployer's SCIM app or custom
With an integration between Simployer and Okta, Simployer One becomes the source of Okta users, so new colleagues, job changes and departures land in Okta from HR. Simployer has its own Okta app with which Okta imports the employees through SCIM; KoppelHet comes in when the manager and the departure date must come along too, or when the subscription does not include SCIM.
What the integration does
Organisations that use Simployer One for HR and Okta for access often switch on Simployer's Okta app first. They then notice that the manager stays empty in Okta and that a departure only shows once the employee is inactive in the import.
- Together we choose the route. If Simployer's SCIM app fits, we set it up; otherwise KoppelHet delivers as a custom HR source in Okta.
- An owner in Simployer One creates a separate access token for the integration, so it can be revoked on its own.
- Every fifteen minutes KoppelHet reads the employees updated since the previous run, with office, department and manager.
- New colleagues arrive in Okta with their work address and the groups of their country and department.
- On the offboarding date, or otherwise the end date, Okta deactivates the user.
What to watch for with Simployer and Okta
- With Simployer's Okta app, Simployer One is the SCIM server and Okta imports the users with profile sourcing; Simployer itself calls Okta an exception, because it serves as the source there but is set up as a server. The attributes then become read-only in Okta. Anyone already using it picks one source when going custom, so Okta does not get two sources for the same profile.
- Simployer's SCIM example returns name, job title, the active status and, from the enterprise extension, employee number, organisation, division, cost centre and department. A manager and the start and end dates are not included. KoppelHet takes those from the regular Simployer One API and fills managerId in Okta.
- Simployer's SCIM entry point returns a work and a private address, and the guide asks for email as the username format in Okta. Without a work address the wrong address can become the login. KoppelHet only uses workEmail or the naming rule, and reports an employee without a work address to HR.
- Besides the end date of the employment, Simployer One has a separate offboarding date. KoppelHet deactivates the Okta user on the offboarding date when it is filled in, and otherwise on the end date, regardless of when Okta's next import runs.
- SCIM at Simployer requires a subscription that allows it, and only an owner can create a token. That token gives owner rights on the whole account. KoppelHet uses a token of its own, only for read calls, and stores it in the platform vault.
- According to the SCIM documentation, Simployer does not sync data back to Simployer One. The work address must therefore be in Simployer before Okta can create the user. For a new colleague KoppelHet checks whether the domain of that address belongs to the Okta environment before the user is staged.
- Simployer is often used by groups with offices in Norway, Sweden and other countries. KoppelHet sets the country of employment as countryCode and as a group in Okta, so apps and policies can differ per country without IT maintaining groups by hand.
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 not just use Simployer's Okta app?
It is often enough when name, job title and department suffice. Choose custom work when the manager or the departure date is needed in Okta.
Can both routes be on at the same time?
Preferably not. Two sources for the same Okta profile cause conflicts. We pick one.
Does KoppelHet read salaries in Simployer?
No. The integration only requests the fields Okta needs.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Standard: the Simployer One Okta app (SCIM 2.0, Simployer as server, import and profile sourcing in Okta, username format email) with an owner's bearer token. GET /scim/v2/Users with userName, name, title, active, emails (work and home) and the enterprise extension (employeeNumber, organization, division, costCenter, department). No write-back to Simployer.
- Custom: Simployer One through the HRM One API (api.alexishr.com/v1, employee with employeeNumber, workEmail, employmentCountry, endDate and offboardDate, filter on updated) and to Okta through a Custom Identity Source (bulk upsert of up to 200 profiles per request, string values only, bulk delete deactivates) or the Users API with an OAuth 2.0 service app.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Simployer | Field in Okta | Notes |
|---|---|---|
employeeNumber | employeeNumber en externalId | |
Voornaam en achternaam | firstName en lastName | |
workEmail | login en email | Never the private address |
Functie | title | |
Afdeling en divisie | department en division | |
Kostenplaats | costCenter | |
Leidinggevende (verwijzing naar medewerker) | managerId | Through the manager's employee number |
employmentCountry | countryCode en groep per land | |
offboardDate of endDate | Deactiveren |
Related
Recruitee → Simployer
Recruitee to Simployer integration: hired candidates with employment and salary in Simployer One
Simployer → Active Directory
Simployer to Active Directory integration: accounts in your own domain from Simployer
Simployer → ADP iHCM
Simployer to ADP iHCM integration: salary, bonuses and end of employment from Simployer One to ADP iHCM
Simployer → AFAS Profit
Simployer to AFAS integration: Dutch employees from Simployer One in AFAS payroll