@Akash Jivane can you help here ?

Hi @Oren Pinkas The "Shared SSO Domain" flow template uses

ssoDomainsTenantsCount

to decide whether to show the tenant selector. This count is based on SSO domain matching — not direct user-tenant associations. Since your internal "Opmed" users log in via Google Social (not SSO), their email domain doesn't match any SSO domain configured on client tenants → the count comes back 0 or 1 → the Switch Tenant screen never renders (or renders empty). The good news: the Switch Tenant component itself does work off user-tenant associations — the problem is the flow logic gating it. Option 1 — Branch your flow for internal users (I would recommended this one) After collecting the email, add a condition that checks if the domain matches your internal domain (e.g.

@opmed.com

). If yes → authenticate via Google Social → show the Switch Tenant component directly (bypassing

ssoDomainsTenantsCount

entirely). If no → continue with the normal HRD/SSO path for client users. For the Switch Tenant component to populate correctly, make sure your internal users are added to each client tenant via the Management API (the Authorization tab on the user profile page doesn't always behave the same way):

POST /v1/mgmt/user/update/tenant/add
{ "loginId": "<mailto:dev@opmed.com|dev@opmed.com>", "tenantId": "<client-tenant-id>" }

Or with the SDK:

descopeClient.management.user.addTenant(loginId, tenantId)

Option 2 — Pre-set tenant via flow parameter Build a lightweight internal portal where devs pick a client tenant, then launch the Descope flow with the

tenant

parameter pre-set. This skips HRD completely and is clean for a dedicated impersonation/support tool. Docs: https://docs.descope.com/auth-methods/sso/with-flows#tenant-flow-parameter Option 3 — Select Active Tenant post-auth Let the dev authenticate via Google Social (no tenant context), then call

POST /v1/auth/tenant/select

from your backend to switch their active tenant to any client tenant on demand. Most flexible for a fully programmatic impersonation flow. Let me know if these options helps you to resolve the issue.

Thank you these options look promising, i'll try and get back to you!

Sure!

@Akash Jivane, thanks for the suggestions! Quick update on my testing: • *Option 3 works great*—this is what I’ll move forward with for now. • Option 1 is still hitting a wall. Even after adding the tenant via the Management API (instead of the UI), the tenant selector remains empty for my Opmed user. I’m curious why the selector isn't picking up that association. Is there a specific configuration or flag I should validate to ensure the component "sees" manually associated tenants? I'd love to dig into this further when you have a moment, but Option 3 keeps me moving. Thanks!

@Oren Pinkas Glad Option 3 is keeping you moving! On Option 1 — the empty selector is almost certainly a flow ordering issue. The Switch Tenant component reads tenant associations from the authenticated user's session, so it needs to be placed after the Google Social authentication step completes, not before. A common mistake is showing the selector screen earlier in the flow (e.g. right after email collection), where the user identity hasn't been resolved yet — so there's no user context to pull tenant associations from. The correct flow order for the internal-user branch: 1. Collect email → condition checks for

@opmed.com

domain 2. Authenticate via Google Social (OAuth step completes here) 3. Then show the screen with the Switch Tenant component Once step 2 completes, Descope has a resolved user session and the component will correctly read all associated tenants from their profile — including those added via the Management API. A quick way to verify the association is working before fixing the flow: after calling

addTenant

, load the user via the API and confirm the

userTenants

array includes the expected tenant IDs:

GET /v1/mgmt/user?loginId=dev@opmed.com

If the tenants appear in that response, the association is correct and the flow ordering is the culprit. Let me know what you find!

@Akash Jivane I see! now it works perfectly, thank you!

Perfect!