Single Sign-On & SCIM

Single sign-on (SSO) lets your team sign in to SalesOS through your company's identity provider (IdP), such as Okta, Microsoft Entra ID, Google Workspace or Auth0. SCIM provisioning lets the same IdP create, update and deactivate SalesOS accounts automatically. Both are set up on one page and are part of the Enterprise plan by default.

Before you start

• You need to be an organization owner or admin in SalesOS.
• You need admin access to your identity provider, to register SalesOS as an application.
• Decide which email domains should use SSO, for example acme.com.

Open Settings → Security & access → Single sign-on (/dashboard/settings/sso). The page is titled Single Sign-On & Provisioning and has two sections: Identity provider and SCIM provisioning.

Setting up the identity provider

Choose a protocol

Under Protocol, pick one:

• OpenID Connect (Okta, Entra ID, Google, Auth0…): usually the quickest to set up.
• SAML 2.0: for IdPs or policies that require SAML.

In Email domains (comma-separated), list every domain whose users should sign in through this IdP.

OpenID Connect

1. In your IdP, create a web application. Copy the Redirect URI to register at the IdP from SalesOS and add it as the allowed redirect or callback URL.
2. Back in SalesOS, fill in Issuer URL, Client ID and Client secret from the IdP application.
3. Leave Scopes as the default unless your IdP needs something different. SalesOS needs the user's email address.

SalesOS discovers the rest of the IdP's settings from the issuer URL. The client secret is stored encrypted. When a secret is already saved, leave the field blank to keep it.

SAML 2.0

1. In your IdP, create a SAML application. Give it the SP entity ID / metadata URL and the ACS (reply) URL shown in SalesOS. Use the copy buttons to avoid typos.
2. In SalesOS, fill in IdP single sign-on URL (entry point) and paste the IdP signing certificate (PEM or base64). IdP entity ID is optional.

Account options

• Create accounts on first sign-in: when someone from your domain signs in through the IdP for the first time, SalesOS creates their account and adds them to your organization.
• Role for new accounts: the role those new accounts get: USER, MANAGER or VIEWER.
• Require SSO (block passwords for these domains): once on, people with these email domains can't sign in with a password. They must use Continue with single sign-on.

Tick SSO enabled, click Save, then click Test connection. For OIDC a successful test shows the issuer it discovered. For SAML it confirms the configuration looks valid.

Turn on Require SSO only after you have signed in through the IdP yourself at least once. Otherwise a mistake in the settings could lock your team out of password sign-in.

How your team signs in

On the SalesOS sign-in page, a user types their work email. If the domain belongs to an organization with SSO, the page shows Continue with single sign-on, followed by your organization's name. Clicking it sends them to your IdP and back into SalesOS, signed in.

Users can also start from the organization's own sign-in link, shown on the settings page after "Users can also start at".

When Require SSO is on, a password sign-in attempt for that domain is refused and the user is sent to single sign-on instead. See Account & Sign-in.

SCIM provisioning

SCIM keeps SalesOS accounts in step with your IdP. People you assign to the SalesOS application are created in SalesOS, profile changes flow through, and people you unassign or deactivate lose access. Groups in your IdP map to teams in SalesOS.

Connecting SCIM

1. Under SCIM provisioning, type a Token label, such as "Okta production", and click Generate token.
2. Copy the token straight away. It is shown only once.
3. In your IdP's SCIM 2.0 connector, set the base URL to the SCIM base URL shown with the token, and use the token as a bearer token.
4. Run a test push from your IdP.

Each token belongs to your organization only. To rotate a token, generate a new one, update your IdP, then click the delete icon on the old token and confirm Revoke token. Your IdP stops provisioning with a revoked token straight away.

What deprovisioning does

When your IdP deactivates or removes a user, SalesOS deactivates their membership. It never deletes the user or their records. Their deals, contacts and activity history stay in place, so you can hand them to someone else with Settings → Data → Mass transfer.

Troubleshooting

• "Continue with single sign-on" doesn't appear: check the email domain is listed under Email domains and that SSO enabled is ticked and saved.
• The IdP says the redirect URI or ACS URL is invalid: copy the value from SalesOS again with the copy button. Trailing slashes matter.
• Users sign in but land without access: check Create accounts on first sign-in and Role for new accounts.
• SCIM calls return unauthorized: the token was revoked or copied incompletely. Generate a new one.