Enterprise SSO Setup
Enterprise single sign-on (SSO) routes sign-in through your organisation's identity provider (IdP), such as Microsoft Entra ID.
When Lleverage activates SSO for a domain, it applies to all users with that email domain, including existing users. Plan the activation with your Lleverage contact and select a few key users to validate sign-in immediately. Lleverage can deactivate the connection again if needed.
1. Plan the Rollout
Before setup:
Choose an activation time with your Lleverage contact.
Select key users who represent the domains and access roles you need to test.
Confirm which users your IdP will let into Lleverage. Without a directory connection, everyone who can sign in joins the Organisation automatically; with one, access comes from your group mappings.
List the primary domain and any additional domains that should use SSO.
Make sure your IT administrator can configure your IdP.
Completing the setup does not change sign-in until Lleverage activates the connection.
2. Configure the Connection
Sign in to Lleverage as an Organisation Owner.
Go to Organisation Settings → SSO, or open
https://app.lleverage.ai/{org-slug}/settings/sso.Enter your primary email domain, such as
acme.com.Select Setup Portal and follow the WorkOS instructions.
Send your Lleverage contact the primary domain and every additional domain that should use SSO.
Agree when Lleverage should activate the connection.
3. Whitelist Users for App Access
Some identity providers only let users open an application after they are explicitly assigned to it. Microsoft Entra ID commonly does this: if the enterprise application requires user assignment, or a Conditional Access policy is scoped to it, unassigned users are blocked at sign-in even though SSO is configured correctly.
To avoid a disruptive activation, whitelist your users before the connection goes live:
In Lleverage, go to Organisation Settings → SSO.
In the User Export card, select Export CSV to download all organisation users and their roles.
In your IdP, assign those users to the Lleverage application, or add them to the group your access policy targets.
Confirm that any Conditional Access policies allow the Lleverage application for those users.
Once your users are whitelisted, tell your Lleverage contact that you are ready. They will put the connection live.
4. Activate and Validate
Once Lleverage activates the connection, all users with a configured domain will use SSO, including existing users.
Validate immediately with your selected users:
Log out of Lleverage or open a private browser window.
Enter the company email address in the regular email login flow. Do not select the Microsoft sign-in button.
Confirm that the user is redirected to your IdP.
Complete sign-in and confirm access to the expected Organisation and Projects.
Test at least one user from each configured domain.
If validation fails, contact Lleverage. The connection can be corrected or deactivated.
Access Requirements
What SSO grants depends on whether the Organisation has a directory connected.
Without a directory connection
Anyone who signs in with an email domain on an active SSO connection joins the linked Organisation, with no invitation:
New and existing users are added to the Organisation with the Member role.
They are also given the Operator role on the Organisation's default Project, which is the oldest Project that has not been archived.
Users who already belong to the Organisation keep the roles they have. Auto-join does not change them.
Control access at the IdP end. Lleverage does not check for an invitation, so any user your IdP allows into the Lleverage application on a configured domain becomes an Organisation member. Restrict application assignment, group membership or Conditional Access policies to the people who should have access.
Still to be done by hand:
Any role above Member at Organisation level, or above Operator on the default Project, has to be assigned by an Organisation Owner.
Access to Projects other than the default has to be granted separately.
With a directory connection
Auto-join stops. SSO authenticates the user, and what they can reach comes from the groups you map in Directory access, which also handles account provisioning and removal. A user who signs in and is in no mapped group sees that nothing is shared with them yet.
Directory access is an Enterprise capability that must currently be enabled by Lleverage for your organisation.
See Roles and Permissions for the current role model.
Common Issues
The Setup Portal link expired
Open Organisation Settings → SSO and select Setup Portal again.
A user is not redirected to the IdP
Use the regular email login flow and ask Lleverage to confirm that the domain is active.
One domain does not work
Ask Lleverage to confirm that the domain is included in the connection.
Sign-in works but the user has no Organisation
Ask Lleverage to confirm that the SSO connection is active. Auto-join only runs while the connection is active and no directory is connected.
Sign-in works but the user cannot build
Auto-join grants Member at Organisation level and Operator on the default Project only. An Owner must grant higher or additional Project access.
A directory is connected and the user sees that nothing is shared with them
They are in no mapped group. See the Directory access FAQ.
All users blocked after activation
Confirm that your users are assigned to the Lleverage application in your IdP, and that Conditional Access allows it.
SSO must be rolled back
Ask Lleverage to deactivate the connection.
Last updated
Was this helpful?