Hi Descopers, how can I use lastAuth to pre-populate context for the current authentication session? The context is that I’m trying to support multiple SSO-configured tenants with the same email domain. I have screens asking the user to enter their email (for domain) and to select a tenant if multiple tenants are configured with the same domain. If a user has a previous login, I want to skip those screens and go straight to SSO with their previous choices. The closest thing I found in the docs was https://docs.descope.com/flows/use-cases/remember-me-flow#3-identify-the-last-authentication-method

Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. A member of the support team will take over and follow up shortly. Key Dynamic Values Use these

lastAuth

keys to access previous authentication context: •

lastAuth.tenantId

- The Tenant ID from the user's most recent authentication •

lastAuth.ssoTenantId

- The SSO Tenant ID used in the most recent authentication (relevant for multiple SSO configurations per tenant) •

lastAuth.ssoId

- The SSO ID for tenants with multiple SSO configurations •

lastAuth.loginId

- The login identifier from the most recent session Implementation Approach 1. Add a condition block early in your flow that checks if

lastAuth.tenantId

exists. 2. Skip tenant selection when a previous tenant is found by routing directly to the SSO action. 3. Pre-populate the SSO action with the stored tenant context. Example Flow Logic Create a condition that evaluates:

lastAuth.tenantId is not empty

If true, route directly to your SSO action using the stored

lastAuth.tenantId

value. If false, continue to your email/tenant selection screens. Using Composite Conditions For more complex scenarios, you can create composite conditions combining multiple

lastAuth

values:

lastAuth.authMethod equals "sso" AND lastAuth.tenantId is not empty

This ensures you only skip screens for users who previously used SSO authentication. The

lastAuth

information persists across sessions, so returning users will have their previous tenant and SSO configuration automatically applied, creating a seamless experience for your multi-tenant setup.

If true, route directly to your SSO action using the stored lastAuth.tenantId value.

this is the part that I don’t understand how to do

@Rahul Rijhwani Can you please assist here ?

Does it just automatically use values from the last auth if they’re available?

Hi Adam, let me clarify how

lastAuth

works with SSO in flows.

lastAuth

values (like

lastAuth.tenantId

) don't automatically get passed into the SSO action — they're available as dynamic values that you can use in conditions to control the flow routing, but you still need to tell the SSO action which tenant to use. Here's how to set this up: 1. Add a Condition at the start of your flow: Check if

lastAuth.tenantId

is not empty (and optionally

lastAuth.authMethod

equals "sso"). This tells you the user has a previous SSO session. 2. Route the "true" branch directly to an SSO action: In the SSO action configuration, the tenant is typically determined by the

tenant

flow input parameter. To make this work automatically for returning users, you'd want to pass the tenant from the client side when starting the flow. 3. On the client/SDK side, when initializing the flow, you can pass the

tenant

parameter. The idea is: • On the first visit, the user goes through email → tenant selection → SSO (the normal path) • After that first login,

lastAuth.tenantId

gets stored in the browser • On the next visit, your flow condition detects

lastAuth.tenantId

is present, and you can use a Set Context action to map

lastAuth.tenantId

→

form.tenant

, which feeds into the SSO action — skipping the manual selection screens entirely. So the key piece you're looking for is likely the Set Context action in the flow to map

lastAuth.tenantId

to the tenant input that the SSO action expects. Here's the relevant docs for reference: • Dynamic Values / lastAuth • Remember Me Flow • SSO with Flows

Thanks for detailed response. I would rather not have to store the last tenant in my application and pass it in explicitly, since Descope already has it in lastAuth. Doing the mapping explicitly in the flow makes sense, but I don’t see a Set Context action in the menu of flow actions. Do I need a Scriptlet for this?

You're right, There isn't a "Set Context" action in the flow editor. A Scriptlet is the right approach here. Here's how to wire it up: 1. Add a Condition to check

lastAuth.tenantId is not empty

2. On the "true" branch, add a Scriptlet action with this configuration: • Arguments: Add a Dynamic argument and map it to

lastAuth.tenantId

• Code: Something simple like:

return { tenantId: lastAuthTenantId };

• Overrides: This is the key part — in the Scriptlet's Overrides section, you can override an existing context key with the Scriptlet's return value. You'd want to override the context key that the SSO action reads for the tenant. 3. The tenant context key to override: the SSO action picks up the tenant from either: •

form.userSelectedTenant

(set by the Switch Tenant component) • Or the

tenant

flow parameter So in your Scriptlet's Overrides, try mapping your returned

tenantId

→

form.userSelectedTenant

. This should make the SSO action behave as if the user had manually selected that tenant via the Switch Tenant component. 4. Then connect the Scriptlet's output directly to the SSO action — skipping the email and tenant selection screens entirely. That said, I want to be transparent — the docs don't explicitly confirm which internal context key the SSO action reads for tenant resolution. If overriding

form.userSelectedTenant

doesn't work, let me know and I can loop in the engineering team to confirm the exact key. Happy to also hop on a quick call to help you configure this in the flow editor!

that’s perfect, thanks! and just to confirm

form.userSelectedTenant

is just the

tenantId

itself, right? I don’t need to set it as some object structure

Yes, that's correct!

form.userSelectedTenant

is just the plain tenant ID string

I wasn’t able to choose either

lastAuth.tenantId

or

form.userSelectedTenant

in their respective dropdowns, so just want to check with you that this looks right

Let me check

It seems to work once I replace

lastAuth.tenantId

with

lastAuth.ssoTenantId

That's the correct fix!

lastAuth.ssoTenantId

is specifically the SSO Tenant ID from the user's last authentication session, whereas

lastAuth.tenantId

is a more general tenant identifier — so for SSO routing,

ssoTenantId

is the right one to use.

lastAuth

didn’t even have a

tenantId

field when I tested. Fortunately,

console.log

works from within the scriptlet

Great!!