Roll out SSO to members
The four ways a member reaches your identity provider after an admin enables organization SSO.
Once you enable SSO, members reach your identity provider through one of four entry points. Which one a member uses depends on their surface (Web or Desktop) and how they arrive.
| Who | Any member (must already be invited to the organization) |
| Applies to | Proliferate Cloud, after an admin enables SSO |
| Affects | The signing-in member |
Enabling SSO adds a sign-in path — it does not replace GitHub sign-in, and it does not force members onto SSO. Connections created from the settings screen have just-in-time provisioning turned off, so invite a person to the organization first (Members & roles).
The four entry points
1. Invitation link
When you invite someone, the invite opens a join link. If the organization has SSO enabled, the link sends them to your identity provider first; membership is accepted in the SSO callback. If SSO can't be resolved, the link hands the invite off to Desktop instead. This is the default path for a brand-new member.
2. Desktop cold login by workspace name
On the Desktop sign-in screen, a member picks Sign in with SSO, enters your organization's workspace name (its slug), and continues. Proliferate resolves the slug to your SSO connection and opens the system browser to your identity provider, returning through a deep link. Desktop does not discover SSO by email domain — it uses the workspace name.
3. Web email-domain discovery
On the Web sign-in screen, a member enters their work email and chooses Continue with SSO. Proliferate looks up the SSO connection by the email's domain and, if a matching enabled connection is found, sends them to your identity provider. GitHub sign-in stays available on the same screen.
4. Direct sign-in link
Web also has a dedicated SSO page at /login, reachable from the Sign in
with SSO link on the sign-in screen. You can distribute a per-organization
link of the form /login/<workspace-name> that pre-fills your workspace name;
the member still clicks Continue to proceed to your identity provider. A
workspace name that does not resolve returns a generic message, so the link
never confirms which organizations exist.
When sign-in is refused
SSO can create the Cloud account for an invited email during the callback — being invited does not mean the account must already exist. What it cannot do without just-in-time provisioning enabled is grant organization membership to someone who was never invited; an uninvited person cannot self-provision through SSO.
| What a member hits | Why | Fix |
|---|---|---|
| SSO isn't offered for their email (Web) | No enabled connection matches the email domain. | Use the domain covered by your connection, or sign in with GitHub. |
| "We could not find single sign-on for that workspace" | The workspace name doesn't resolve to an enabled connection. | Share the correct sign-in link or workspace name. |
| Sign-in is rejected after authenticating at the provider | The email domain isn't in the connection's allowed domains, or the provider didn't return a verified email. | Add the domain, or have the member sign in with a matching, verified account. |
| "Not a team member" | They authenticated but were never invited to the organization. | Invite them first, then have them sign in again. |
Admins diagnosing these cases can see the underlying causes in Troubleshooting.