---
summary: Business guide for using SigID organizations, verified domains, SSO, provisioning, fallback access, and role mapping.
tags:
  - business
  - organizations
  - sso
  - provisioning
categories:
  - For Business
---

# Organizations And SSO

<!-- agent:page
You are an AI agent helping a workspace admin set up a SigID organization with domains, SSO, role mapping, and fallback access for a company, customer, partner, or internal team.
Ask up front: the customer or team name, the email domain(s) involved, which identity provider they use, whether every user from the domain must use SSO, which roles organization owners may manage themselves, whether automated provisioning or deprovisioning is required, and who supports identity-provider problems.
Follow the eight-step SSO Setup Flow: create the organization, verify the domain if domain ownership matters, connect the identity provider, decide which users must use SSO, map identity-provider groups or claims to roles your app understands, test sign-in with a real user from that organization, decide the fallback path if the identity provider is unavailable, and confirm support ownership before rollout. Configuration happens in the Dashboard at dashboard.sigid.org.
Success: a real user from the organization completes SSO sign-in and returns to the app, role mappings resolve correctly, and an emergency path exists for SSO misconfiguration.
Pitfalls: forcing SSO before the connection is tested (locking out invited users), and rolling out with no fallback for when the identity provider is unavailable.
Domain verification (DNS at the registrar) and identity-provider configuration happen in consoles only the customer's human admins can access; you prepare the exact values, instructions, and verification for them.
-->

Use this page when a company, customer, partner, or internal team needs its own
membership, domain, sign-in policy, or role mapping.

## What Organizations And SSO Mean

An organization is a container for a customer or team. It helps you manage that
group's members, domains, roles, and sign-in rules.

SSO lets users sign in through their company's identity provider. SigID handles
the connection between your app and that provider, then returns the user to
your app after sign-in.

## When To Use Organizations

<!-- agent:action Decide if organizations fit
Confirm at least one trigger applies: a customer or team managing its own members, domain-based access rules, company SSO, customer-specific roles, audit events grouped by organization, or provisioning/deprovisioning from an identity provider.
If none applies - for example a simple public app where every user signs in directly as an individual - tell the admin an organization is not needed and stop here.
Record which triggers apply; they shape the SSO Setup Flow steps you will need.
-->

Use organizations when you need:

- one customer or team to manage its own members
- domain-based access rules
- company SSO
- customer-specific roles
- audit events grouped by organization
- provisioning or deprovisioning from an identity provider

You may not need organizations for a simple public app where every user signs in
directly as an individual.

## SSO Setup Flow

<!-- agent:action Run the SSO setup
Execute the eight steps in order: create the organization, verify the domain if domain ownership matters, connect the identity provider, decide which users must use SSO, map identity-provider groups or claims to roles your app understands, test sign-in with a real user from that organization, decide the fallback path if the identity provider is unavailable, and confirm support ownership before rollout.
Domain verification and the identity-provider connection require the customer's human IdP admin - prepare the exact values and instructions for them.
Do not enforce SSO for the domain until the step-6 real-user test passes.
-->

1. Create the organization for the customer or internal team.
2. Verify the domain if domain ownership matters.
3. Connect the identity provider.
4. Decide which users must use SSO.
5. Map identity-provider groups or claims to roles your app understands.
6. Test sign-in with a real user from that organization.
7. Decide the fallback path if the identity provider is unavailable.
8. Confirm support ownership before rollout.

## Questions To Decide Early

<!-- agent:action Settle SSO policy questions
Get the admin's answer to every question: should every user from this domain use SSO, can invited users sign in before SSO is fully configured, which roles can organization owners manage themselves, is automated provisioning required, who supports users when the identity provider blocks access, and what is the emergency path if SSO is misconfigured.
Record the answers before configuring SSO enforcement.
The emergency path is mandatory - do not roll out without one.
-->

- Should every user from this domain use SSO?
- Can invited users sign in before SSO is fully configured?
- Which roles can organization owners manage themselves?
- Is automated provisioning required?
- Who supports users when the identity provider blocks access?
- What is the emergency path if SSO is misconfigured?

For deeper API or provisioning details, use
[Reference: API And SDK Reference](../reference/api-sdk-reference.md).