SSO and Auto-Provisioning

Overview

Auto-provisioning registers a customer’s single sign-on (SSO) organization identifier so that matching users are created in Synthreo automatically the first time they sign in. You can also enforce SSO, so matching users must sign in through their provider rather than with a password.

These controls appear in two places, and work the same in both:

• Your organization - in Settings, inside the Authentication card, under “SSO & auto-provisioning” and “SSO access”.
• A child customer - on the customer’s Authentication tab, which carries both. See Adding a New Customer.

Note

These used to be two separate customer tabs, SSO / Provisioning and SSO Access. They are now one tab named Authentication. Old links to the SSO Access tab redirect there automatically.

---

Provisioning rules

A provisioning rule maps an SSO organization to your Synthreo tenant. Select the add control to open Add Provisioning Rule, which describes itself as “Register a customer’s SSO org identifier so matching users are provisioned automatically.”

Field	What to enter
Name	Required. A label for the rule, for example “Contoso (Entra)”.
Provider	Required. Pick from the providers listed. The list is served by the platform and may change over time.
Identifier	Required. The provider’s organization identifier. For Microsoft Entra this is the Directory (tenant) ID - the GUID shown under Microsoft Entra ID in the Azure portal, for example 00000000-0000-0000-0000-000000000000. The field shows the expected format for whichever provider you picked.
Granted apps	Which apps provisioned users receive. ThreoAI is checked and locked - every provisioned user gets it. The rest are optional.
Create disabled	”Create disabled (rule is saved but not applied)”. Use this to stage a rule before it takes effect.

Save to create it. Rules appear in the table with their name, provider, identifier, apps, created date, and enabled state. With none yet, the table reads “No provisioning rules yet.”

Note

Provider and identifier are fixed after creation. Editing an existing rule lets you change only its name, granted apps, and disabled state. To point at a different SSO organization, create a new rule and remove the old one.

---

Enforcing SSO

The Enforce SSO toggle stays off, and cannot be turned on, until at least one provisioning rule exists - the control reads “Add a rule to enable enforcement.” until then. Once a rule is in place, turn it on so that users matching a rule must sign in through their SSO provider rather than with a password.

---

SSO access

The SSO access view manages the users that auto-provisioning has created and the ones you want to keep out:

• Active users - users auto-provisioned for this organization, with their email, provider, identifier, and when they were provisioned. Deny a user to block re-provisioning on their next sign-in.
• Denied emails - the block list. Block email adds an address; the list shows when each was blocked and why. Allowing an email re-enables provisioning on that person’s next sign-in.

---

Related

• Settings - where your organization’s SSO settings live
• Adding a New Customer - the per-customer SSO tabs
• Managing User Permissions - roles and access for provisioned users