We use the built-in

sign-in-social-or-sso-with-magic-link-mfa

flow, but in many occasions tenants that have SSO configure still click "continue with google" which doesn't work and causes confusion. Is there a suggested way to create a flow that the user enters the mail or something, and then based on the tenant configuration redirects to the right place? to the idp if sso is configured, or the the google social login?

Custom Flow with Email-Based Routing Create a custom flow that collects the user's email first, then routes them based on tenant SSO configuration. This prevents the confusion with social login buttons. Flow Structure 1. Email input screen 2. Condition to check SSO configuration 3. Route to appropriate authentication method

Email Input → Condition → SSO Action (if configured)
                      → Social/Magic Link (if not)

Implementation Steps 1. Create a new flow with an email input component 2. Add a condition block using

ssoEnabled

and

tenant.enforceSSO

keys 3. Connect SSO action for tenants with SSO configured 4. Connect social login/magic link for others Condition Logic Use these condition keys to determine routing: •

ssoEnabled

- checks if SSO is configured for the tenant •

tenant.enforceSSO

- checks if SSO is enforced The flow automatically handles tenant identification based on email domain . If multiple tenants share the same domain, use the

ssoDomainsTenantsCount

key to show a tenant selection screen . This approach eliminates the "continue with google" confusion by routing users to their correct authentication method based on their tenant's actual configuration. SSO Enforcement in Flows | Descope Documentation SSO Authentication | Descope Documentation SSO with Flows | Descope Documentation

is there any built-in flow that does that?

No, there isn't a built-in flow that does exactly what you need. The existing

sign-in-social-or-sso-with-magic-link-mfa

flow shows all authentication options upfront, which creates the confusion you mentioned. Available Built-in Flows The closest built-in options are: • Standard social/SSO flows that show all methods immediately • Magic link flows with email scanner protection Solution: Custom Flow Required You'll need to create a custom flow that: 1. Collects email first 2. Uses conditional logic to route based on tenant SSO configuration 3. Hides social login options when SSO is configured The domain-based SSO detection is built into Descope , but you need to structure the flow to leverage this properly. The platform automatically detects SSO-enabled domains when users input their email , but the routing logic requires custom flow design. This approach eliminates the "continue with google" confusion by only showing relevant authentication methods based on the user's actual tenant configuration. Checking for Email Scanners | Descope Documentation The Power of Descope Flows: Enforcing SSO for SSO-Enabled Domains

Is this the nicest experience? How do I show the social login only if sso is not configured?

You're right - requiring email input first isn't the nicest UX. Here's how to show social login only when SSO isn't configured: Better Approach: Conditional Social Login Display Create a flow that dynamically shows/hides social login buttons based on tenant SSO configuration. Implementation Steps 1. Start with an email input screen 2. Add a condition block checking

ssoEnabled

and

tenant.enforceSSO

keys 3. Route to different screens based on SSO status:

Email Input → Condition → SSO Screen (if SSO enabled)
                      → Social + Magic Link Screen (if no SSO)

Screen Configuration • SSO Screen: Only shows SSO button and magic link (if allowed) • Social Screen: Shows Google, other social providers, and magic link • Use screen conditions to control which authentication methods appear Dynamic Button Display You can also use the

ssoEnabled

condition within a single screen to conditionally show/hide social login buttons. This creates a cleaner experience where users see only relevant options after entering their email. Alternative: Domain-Based Routing For the smoothest UX, configure SSO domains properly so tenant detection happens automatically based on email domain, then use conditional screens to show appropriate authentication methods. This approach gives users the right options without confusion while maintaining a clean, contextual interface. SSO Enforcement in Flows | Descope Documentation SSO Authentication | Descope Documentation

Hi @Sharon, take a look at this template: https://app.descope.com/flows?template=sso-magic-link-template-sign-in When entering email it will redirect the user to the relevant IdP if SSO is configured, based on the email domain. When using social login, it will do the same, but this time by using the incoming users email from the social provider.

Hey @Tal Kapitolnik, What happends if someone clicks "continue with sso" but it is not enabled? can I disable the whole magic link stuff?

There is no continue with SSO button in the flow I sent you. There is a condition that checks if SSO is enabled, if not we send a magic link. You can change this to do something else if you want a different method.

I see, but when I try that, I see a new user with the google login id without any tenant is created - does that make sense? I'm available for a quick call if that's better

Yeah it makes sense. What you need to do is to add the email domain to the tenants email domain. It will automatically add the created user in the relevant tenant, and will merge them after the SSO.

to the sso domain you mean? it's already there

To here, not related to SSO

But I don't want to enable self registration if SSO is not enabled

If you don't want to allow self registration, change the action to

Sign In / OAuth

instead of sign up or in

but them I get an error that the user does not exists, what I was looking for is to just use this email to redirect to the sso flow

So there is a solution for it too 🙂 We can read the OAuth response and set the form.email to the one from the response.

Yeah that seems to work much better, thanks!

If enforce SSO is configured than it won't let the user login to the tenant without SSO, you don't need to handle it in the flow.

what about sso exclusion list? is that checked in the ssoEnabledIgnoreUser part?

The SSO exclusion also works automatically, it will let you login with the user via social if its in the list.

Even if this check using the "IgnoreUser" version? that seems odd, ur just the name is a bit misleading

Now I understand what you are asking, let me check that.

It seems to work, must admit that I'm not sure how 🙂