Organizations And SSO¶
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¶
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¶
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.
- Create the organization for the customer or internal team.
- 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.
- Confirm support ownership before rollout.
Questions To Decide Early¶
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.