What is SCIM?
SCIM (System for Cross-domain Identity Management) is an open standard that facilitates the automation of user provisioning. Jiminny supports both automatic and manual provisioning of users via the SCIM protocol, allowing organizations to manage user data more efficiently by syncing it directly from their Identity Provider (IdP) to Jiminny.
In essence, SCIM allows customers to add employees to their HR system, and these users will automatically be created in Jiminny. This integration streamlines the onboarding and offboarding processes by enabling centralized management of user data
Supported Identity Providers
Jiminny officially supports the following Identity Providers (IdP):
Microsoft Entra ID (formerly Azure Active Directory)
Okta
Supported Features
Push New Users: New users created in a supported IdP are automatically provisioned in Jiminny.
Push User Updates: Updates made to user profiles in a supported IdP are automatically reflected in Jiminny.
Push User Deactivation: When a user is deactivated or their access is disabled in a supported IdP, the user is deactivated in Jiminny.
Push User Reactivation: Reactivating a user in a supported IdP will reactivate the user in Jiminny.
Push Groups: Existing IdP groups and their memberships can be pushed to Jiminny, where they are managed by the IdP.
Assign Roles: User roles can be assigned and updated directly from a supported IdP, so you don't need to set them manually in Jiminny.
Setting Up SCIM with Jiminny
1. Request a SCIM Endpoint:
Clients should open a Service Request (SRD) ticket to request a SCIM endpoint from Jiminny. This endpoint, provided by Jiminny’s Engineering team, is necessary for configuring SCIM on the client’s IdP.
2. Configure the SCIM Endpoint on the Identity Provider:
Clients should send the SCIM endpoint, along with the applicable setup guide, to their IT team.
After configuration, users and groups will be automatically created and managed in Jiminny via the client’s IdP.
Okta
Okta
Enable SCIM Provisioning in your Application
Set SCIM
connector base URLto the endpoint providedSet
Unique identifierfield touserNameSelect
Push New Users,Push Profile UpdatesandPush GroupsSelect
HTTP HeaderforAuthentication ModePaste your Bearer token provided into the
AuthorizationheaderClick
Test Connection ConfigurationandSave
Managing roles via SCIM
Jiminny reads user roles from the standard SCIM roles attribute, so you can assign and update roles directly from your IdP as part of normal provisioning.
Note: Because roles is part of the core SCIM schema, most IdPs support it — but it isn't always included in the default attribute mapping . If roles aren't already in your IdP's mapping for Jiminny, add it before assigning roles.
Each user has one primary role plus an optional permission layered on top — up to two values in total.
Primary roles
Value | Role |
recorder | Record meetings |
recorder_and_voice | Recorder, plus Jiminny Voice dialer capabilities (available only on some plans) |
analyst | Read-only access for coaching and review — the default for new users |
listener | Listen to recordings only (available only on some plans) |
Permissions (optional)
Value | Permission |
user | Standard access, no admin capabilities (default) |
manager | Manage teams and invite users |
admin | Manage integrations and organization-level settings |
Note: Role values are not case sensitive, and surrounding spaces are ignored — admin, Admin and ADMIN are all read as the admin permission.
How role assignment behaves
New users with no role are created as analyst with no permission.
Primary role and permission are applied independently: if you send only a permission, the user keeps their current primary role; if you send only a primary role, they keep their current permission.
listener can't be combined with manager or admin. Switching a user to listener clears any admin or manager permission they had.
Unrecognised values are ignored. If every value sent is unrecognised, existing users keep their current roles and new users default to analyst.
Removing a permission
There are two ways to take a manager or admin permission away from a user.
Send user as the role value, which replaces the permission with standard access:
“roles”: [{“value”: “user”}]
Or send a SCIM remove operation naming the permission. Both of these work:
{“op”: “Remove”, “path”: “roles”, “value”: [{“value”: “admin”}]}
{“op”: “Remove”, “path”: “roles[value eq \“admin\“]”}
Either way the user keeps their primary role and simply loses the elevated permission.
Removing a primary role has no effect — every user must have one, so Jiminny keeps the role they already have. To change someone’s primary role, send the new one instead of removing the old one.
Note: A remove will not take the admin permission away from your organisation’s CRM Owner. That user keeps admin so the CRM connection cannot be orphaned.
Role value format
Roles are sent in the roles attribute as an array — order doesn't matter:
"roles": [{"value": "recorder"}, {"value": "admin"}]A simple string array is also accepted:
"roles": ["recorder", "admin"]
Jiminny also accepts a single role object, and a role object sent as a JSON string, which is how Microsoft Entra ID sends app role assignments. Any extra sub-attributes an IdP includes alongside the role — such as id, displayName, type or primary — are ignored. Only value is read.
Configuring roles in Microsoft Entra ID
In Entra, the roles attribute is populated from the app roles you assign to a user. Jiminny reads the app role’s Value field, so that field must contain one of the values from the tables above. The Display name can be anything you like — it is only shown inside Entra.
An Entra SingleAppRoleAssignment expression returns exactly one value per assignment, so a single mapping expression can set a primary role or a permission, but not both at once. To set both, create two app roles and map them separately — for example a recorder app role and an admin app role. Jiminny applies each one independently, so the user ends up with both.
If you only need to set a primary role and are happy for users to have no elevated permission, one app role is enough.
Good to know
Jiminny does not support attribute re-mapping
userName is not used as the primary identifier to map users, instead primary work email is used.