Identity and access management
Sage People to Okta integration: Okta users from team members and employment records
With an integration between Sage People and Okta, every new team member from Sage People gets an Okta user with job title, department, country and manager, and the start and end date of the employment record decide when access opens and closes. The Sage People app in the Okta Integration Network is meant for sign-in; KoppelHet reads the team members through Sage People's Salesforce API and delivers them to Okta.
What the integration does
Organisations that use Sage People for several countries and Okta as their identity provider have often already set up signing in to Sage People through Okta. IT still processes new colleagues and leavers in Okta by hand, based on notifications from HR.
- The Sage People administrator creates an API user with read-only rights on team members and employment records.
- KoppelHet reads the changed records and stages a new colleague in Okta, not yet active.
- On the start date of the employment record KoppelHet activates the user; groups per country and department decide the apps.
- The Okta address becomes the Federation Id in Sage People, so sign-in through Okta finds the right user.
- The day after the end date KoppelHet deactivates the Okta user.
What to watch for with Sage People and Okta
- In the Okta Integration Network Sage People is listed under single sign-on, with an entry that has not been updated since 2018. An HR source that creates Okta users from Sage People is not part of it. KoppelHet supplies that flow, and sign-in through Okta stays as it is.
- When signing in through an identity provider, Sage People compares the assertion with the username or the Federation Id, and recommends the Federation Id because usernames must be unique across all of Salesforce. KoppelHet uses the Okta login as Federation Id, so sign-in to Sage People lines up from day one.
- In Sage People the person and the employment are separate records, and the end date belongs to the employment record. A departure therefore does not change the team member itself. KoppelHet follows changes on both objects, so Okta does not miss a departure.
- After a return, a team member gets a new employment record in Sage People. An Okta Custom Identity Source works with a fixed external key per user. KoppelHet uses the team member as key and not the employment record, so a returning colleague gets their old Okta user back instead of a second one.
- Sage People links each employee to a country through the payroll company. KoppelHet puts that country into Okta and uses it for groups, so apps that only apply in one country do not reach colleagues elsewhere.
- KoppelHet signs in to Sage People through its own app with client credentials and an API user with read-only rights. The integration therefore does not depend on the password of an HR employee, and salary or bank details are not in the rights.
- HR often records an end date in Sage People weeks ahead. KoppelHet deactivates the Okta user on the day after that date, not at the moment of entry, so a leaver can reach their apps up to and including the last day.
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
Does this work with several countries?
Yes. The country comes from the payroll company and drives groups in Okta.
Does the integration see salaries in Sage People?
No. The API user only has read rights on the fields for the account.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Sage People through the Salesforce API with SOQL on fHCM2__Team_Member__c and fHCM2__Employment__c, filtered on the modification date of both objects; signing in through an External Client App with OAuth 2.0 client credentials and an API user with a read-only permission set. Federation Id is set by the Sage People administrator or by KoppelHet if the API user has that right.
- To Okta through the Users API with an OAuth 2.0 service app (create without activation, activate, deactivate) or through a Custom Identity Source (Identity Sources API with an immutable externalId per user, bulk upsert and bulk delete).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Sage People | Field in Okta | Notes |
|---|---|---|
Employee Number (team member) | employeeNumber | |
First Name en Last Name | firstName en lastName | |
Naamgevingsregel | login en email | |
Job Title | title | |
Department | department | |
Land van de payroll company | countryCode en groepen | |
Manager (team member) | managerId en manager | |
Start Date en End Date (employment) | status (STAGED, ACTIVE, DEPROVISIONED) |
Related
Sage People → Active Directory
Sage People to Active Directory integration: domain accounts for the Dutch office
Sage People → ADP iHCM
Sage People to ADP iHCM integration: salary records, bonuses and leavers of the Dutch payroll company to ADP
Sage People → AFAS Profit
Sage People to AFAS integration: Dutch employees and salaries from Sage People in AFAS Profit
ASSage People → Arbodienst (SIVI)
Sage People to the occupational health service via SIVI: absence records as absence reports