DOCS

SSO & SCIM

Single sign-on (SAML/OIDC) and directory provisioning for Enterprise workspaces.

Available on Enterprise. Both are configured in Settings → Single sign-on.

SSO

RepCue supports SAML 2.0 and OIDC identity providers (Okta, Entra ID, Google Workspace, OneLogin, JumpCloud and any standards-compliant IdP).

  1. In Settings → Single sign-on, click Set up SSO. You'll get the ACS URL, entity ID and metadata for SAML, or the redirect URI for OIDC.
  2. Create the application in your IdP with those values and paste the IdP metadata URL (or client id/secret) back.
  3. Add your verified email domains. Users signing in with those domains are routed to the IdP.
  4. Test with your own account, then toggle Enforce SSO to disable magic links for the domain.

Just-in-time provisioning

When a user from a verified domain signs in through the IdP for the first time, RepCue creates their account as a rep and consumes a seat. If no seats remain, sign-in fails with a clear message and the admin is notified. Turn JIT off if you want SCIM to be the only way accounts are created.

Desktop app

The desktop app signs in through the system browser, so SSO works unchanged: the rep lands on your IdP, and the session deep-links back into the app.

SCIM 2.0

Provisioning keeps seats accurate and deprovisions leavers the moment IT does.

  1. Settings → Single sign-on → SCIM → Generate token. Copy the base URL and bearer token.
  2. In your IdP's provisioning settings, enter:
    • Base URL: https://api.repcue.io/scim/v2
    • Bearer token: the generated token
  3. Enable Create users, Update attributes, Deactivate users and, optionally, Push groups.

Supported: Users (create, read, replace, patch active, delete → deactivate), Groups (see below), ServiceProviderConfig, Schemas, ResourceTypes, and filter=userName eq "…".

Deactivating a user in the IdP ends their sessions, frees the seat and keeps their calls for the organisation. Rotating the SCIM token invalidates the old one immediately.

Groups: roles and teams

Pushed groups do two different jobs, distinguished by name:

  • Groups named admins, managers or reps map to a RepCue role.
  • Any other group becomes a team ("Enterprise West", "SMB Team", "EMEA") with its memberships.

That second rule matters more than it looks. Teams are what manager read scoping, goals, digests and per-team policies key off, so an IdP that already models your sales organisation configures RepCue's internal access control for free, with no second setup. Group ids for teams are namespaced team_<uuid>, so the role and team namespaces cannot collide.

Removing someone from a group removes them from the team. See Teams & org chart and Roles & permissions.

Roles

RoleCan
repRun calls, see their own calls, deals and coaching, use the HUD
managerEverything a rep can, plus their teams' calls and analytics, live floor (listen-in, whisper), coaching review, playbooks, team goals
adminEverything org-wide, plus people, teams, billing, integrations, consent, policies, retention, SSO/SCIM, API keys, webhooks, audit log

Roles are a hierarchy, but they are not the whole access story: what a manager can read is bounded by the teams they manage, and a rep is always scoped to themselves. The full rules, including why an out-of-scope record answers 404 rather than 403, are in Roles & permissions.

The last admin in an organisation can't be demoted or deactivated.