> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bindbee.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Set Up Single Sign-On

> Let your team sign in with your own identity provider.

With SSO enabled, your team reaches the Bindbee Dashboard through your existing identity provider - they enter their work email and authenticate where they already do. Setup is a one-time exchange with Bindbee rather than something you configure in the Dashboard.

<Info>
  **Before you start**

  * You're an Admin in your Bindbee organization. See [Roles & permissions](/guides/workspace/roles-and-permissions).
  * You have a route to whoever administers your identity provider - the setup happens in their system, not in Bindbee.
</Info>

## Steps

<Steps>
  <Step title="Ask Bindbee to start the setup">
    Email [support@bindbee.dev](mailto:support@bindbee.dev) with your organization and the identity provider you use. Bindbee prepares the connection and sends you back a setup link.

    **Result:** You have a link to hand to your identity provider's administrator.
  </Step>

  <Step title="Complete the configuration in your identity provider">
    Your administrator opens the link and finishes the setup on their side. Nothing else is needed from Bindbee once they're done.

    **Result:** The connection between your provider and Bindbee is established.
  </Step>

  <Step title="Add each person to the organization">
    SSO decides *how* someone signs in, not *whether* they have access. Every user must still exist in your Bindbee organization with an Admin or Member role, added by an Admin.

    **Result:** Everyone who needs the Dashboard has an account and a role.
  </Step>

  <Step title="Sign in with a work email">
    On the Bindbee sign-in page, the user enters their email and is sent to your provider to authenticate. No Bindbee password is involved.

    **Result:** They land in the Dashboard with the permissions their role carries.
  </Step>
</Steps>

<Note>
  The two halves stay separate for the life of the organization. Removing someone from your identity provider stops them authenticating through it, but **remove them from the Bindbee organization as well** - and add them there first when someone joins, or their first sign-in fails.
</Note>

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="A user authenticates with your provider but still can't get in">
    They haven't been added to the Bindbee organization yet, or were added under a different email than the one their provider returns. An Admin adds them, and the email must match.
  </Accordion>

  <Accordion title="A user is in but can't do something they expect to">
    That's their role, not SSO. User management, the Production API key, Production connector deletion and SFTP credentials are Admin-only - see [Roles & permissions](/guides/workspace/roles-and-permissions).
  </Accordion>

  <Accordion title="You need to change or remove the connection">
    Both go back through [support@bindbee.dev](mailto:support@bindbee.dev). Include your organization name and what's changing - a new provider, a new domain, or removing SSO entirely.
  </Accordion>

  <Accordion title="Sign-in fails before reaching your provider">
    Send support the email address used and the time of the attempt. Without both, the failure is hard to place - it could be the address, the organization, or the provider connection.
  </Accordion>
</AccordionGroup>

## Related

* [Roles & permissions](/guides/workspace/roles-and-permissions) - what each role can do once they're in
* [Authentication](/api-reference/basics/authentication) - API keys, which SSO does not change