> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/administer-and-govern/control/members/sso-setup.md). # Enterprise SSO Setup Enterprise single sign-on (SSO) routes sign-in through your organisation's identity provider (IdP), such as Microsoft Entra ID. {% hint style="warning" %} 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. {% endhint %} ## 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 1. Sign in to Lleverage as an Organisation Owner. 2. Go to **Organisation Settings → SSO**, or open `https://app.lleverage.ai/{org-slug}/settings/sso`. 3. Enter your primary email domain, such as `acme.com`. 4. Select **Setup Portal** and follow the WorkOS instructions. 5. Send your Lleverage contact the primary domain and every additional domain that should use SSO. 6. Agree when Lleverage should activate the connection. {% hint style="info" %} Always open the Setup Portal from the SSO Settings page. Links shared by email are temporary and can expire. {% endhint %} ## 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: 1. In Lleverage, go to **Organisation Settings → SSO**. 2. In the **User Export** card, select **Export CSV** to download all organisation users and their roles. 3. In your IdP, assign those users to the Lleverage application, or add them to the group your access policy targets. 4. 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: 1. Log out of Lleverage or open a private browser window. 2. Enter the company email address in the regular email login flow. Do **not** select the Microsoft sign-in button. 3. Confirm that the user is redirected to your IdP. 4. Complete sign-in and confirm access to the expected Organisation and Projects. 5. 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. {% hint style="warning" %} 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. {% endhint %} 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](/administer-and-govern/control/members/directory-access.md), 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](/administer-and-govern/control/members/roles-and-permissions.md) for the current role model. ## Common Issues | Issue | Action | | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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](/administer-and-govern/control/members/directory-access/faq.md). | | 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. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lleverage.ai/administer-and-govern/control/members/sso-setup.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.