Automates the creation, update, and deactivation of employees in Whalemate based on the data that already exists in Okta.
Eliminates manual or file-based payroll uploads.
Keeps Okta groups synchronized with groups in Whalemate.
Centralizes the source of truth for employee data in Okta, reducing inconsistencies.
This integration is enabled per company. If in Configuración → Integraciones you don't see the Okta card inside Importación Automática de Empleados, write to us and we'll enable it on your account.
Be careful not to confuse the two Okta integrations. The Okta card in Importación Automática de Empleados is the one that synchronizes payroll, and it's the one described in this article. Okta sign-in is a different setting, with its own article.
Go to Configuración → Integraciones, locate the Okta card, and click Importar. The Integración SCIM - Okta dialog opens, explaining the two pieces of data you need and containing the Generar Token Bearer button.
Once generated, the dialog switches to Okta | Sincronización exitosa and shows the two fields, each with its own copy button:
Token Bearer — the authentication credential for the calls.
Endpoint — the address to which Okta will send requests. Copy it from there instead of typing it manually: Okta's is not the same as Microsoft's, and the dialog gives you the one that corresponds to your integration.
The Token Bearer is shown only once. Copy it and store it somewhere safe before closing the dialog with Listo: afterward it can't be viewed again.
Generate the token only once, when you're about to set up Okta. If you generate a new one, that's the one Okta has to use: until Okta makes its first call with it, the card will keep showing as if the integration weren't running. If you need to replace it, generate the new one and update it in Okta during the same session.
In the Okta application you're going to use for Whalemate, configure the SCIM connector with these values:
SCIM connector base URL: the Endpoint you copied in the previous step.
Authentication Mode: HTTP Header with Bearer Token.
Token: the Token Bearer you copied in the previous step.
Unique identifier field for matching: username (userName).
The provisioning actions you can enable, because Whalemate supports them, are:
Create Users
Update User Attributes
Deactivate Users
Push Groups, with member additions and removals
This is the correspondence between the SCIM attribute Okta sends and the employee field in Whalemate:
userName → Email
emails[0].value → Email
name.givenName → First name
name.familyName → Last name
addresses[0].country → Country
preferredLanguage → Language
title → Position
department (enterprise extension) → Department
externalId → Personal ID
The field worth reviewing before syncing is
externalId. It's the value that fills the employee's Personal ID field, and it's also one of the two data points Whalemate uses to recognize a person across syncs —the other is the email—. If you use the personal ID to cross-reference payroll with another system, mapexternalIdto the Okta attribute that has that number (for example, the employee number). If you leave it with Okta's internal identifier, your employees' personal ID will end up with that value.
Assign to the application the people and groups you want to sync, and enable provisioning. From that point on, every creation, change, or deactivation in Okta flows to Whalemate.
The Okta card in Configuración → Integraciones updates itself when the first request arrives: instead of the Importar button, it now shows Información and the date of the last sync.
Email is one of the pieces of data Whalemate uses to identify an employee, and it's resolved in this order:
The address marked as primary in Okta.
If none is marked as primary, the first one in the list of emails.
If no address arrives, the username, as long as it's an email address.
If neither a usable email nor a usable username arrives, that person is not created and the attempt is logged.
A group pushed from Okta is created in Whalemate with the same name, and its members are assigned automatically.
Adding or removing people from the group in Okta adds or removes them from the group in Whalemate.
Renaming the group in Okta renames it in Whalemate.
Removing the group from provisioning deletes the group in Whalemate, but does not delete the people: they remain on the platform with their history, without that group.
If you already have a group with the same name in Whalemate, the Okta group is not created and the attempt is logged as a duplicate name. This is the first thing worth checking if you pushed groups and one of them didn't show up: rename the existing group in Whalemate, or the one in Okta, before syncing again.
Deactivating or suspending a person in Okta deactivates them in Whalemate and removes them from all their groups.
Reactivating them in Okta restores their record with the history it had, instead of creating a new one. Their groups don't come back automatically: you have to reassign them, either from Okta by including them in the pushed group again, or manually on the platform.
The same applies if you add back someone you had deactivated: if the email or personal ID matches a deleted employee, provisioning restores their record instead of duplicating it.
In Configuración → Integraciones, with the integration running, the Okta card shows the Información button. The Okta | Detalles de SCIM dialog provides the sync status, the date and time of the last one, and two actions:
Ver registros de integración — opens Registros de integración filtered by Okta: the detail of every creation, update, and deactivation, with which field changed, its previous value and the new one, the result, and, if something failed, the cause. The Origen field distinguishes changes that arrived via SCIM from those made manually by someone.
Eliminar sincronización — cuts off the integration.
Eliminar sincronización acts immediately and cannot be undone. It deletes the integration credentials, so provisioning from Okta stops working at that moment. To reconnect it, you need to generate a new token and reconfigure the application in Okta. Employees already imported are not deleted.
I generated the Token Bearer and the card still shows "Importar." Is something broken?
No. The card changes when the first request from Okta arrives, not when the token is generated. If you already enabled provisioning and the card still looks the same, check in Okta that the connector base URL and token are the ones you copied from the dialog.
Can I view the Token Bearer again if I lose it?
No. It's shown only once when generated. If it's lost, you need to generate a new one from the same card and update it in Okta.
Which attribute do I need to review before syncing?externalId, because it's the one that fills the employee's Personal ID. If you need your employee number to go there, map it to the Okta attribute that has it.
I pushed a group from Okta and it doesn't appear in Whalemate.
Most likely a group with that name already exists on the platform: in that case the group is not created and the attempt is logged. Check it in Registros de integración and rename one of the two.
I deactivated someone in Okta by mistake and reactivated them. Did they lose their history?
No, their record is fully restored. What doesn't come back automatically are their groups: you have to reassign them.
Does the same configuration as Microsoft's work?
No. Okta's Endpoint is different, and so is the externalId mapping: in Okta that attribute fills the Personal ID. Always copy the endpoint from the Okta card's dialog.
Do you have feedback or want to request improvements? Let us know at roadmap.whalemate.com/roadmap
