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 Azure Active Directory (AD)
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 |
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.
To remove a manager or admin permission, send user.
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.
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"]
Limitations
Jiminny does not support attribute re-mapping
userName is not used as the primary identifier to map users, instead primary work email is used.