this is my flow i am using for sign up or sign in process with bring your own screen feature where first PKCE flow is run to generate auth code. then sent to BYOS screen where signup or signin happens then go to backend for code verification. in the sign up sign in screen i have one edge case where i want to check email address domain is associated with sso login type or normal email/password flow. but using flow it is checking the password and i am not able to figure out how i can set condition between verifying password disclaimer: i cannot seperate by puting email address first then show passowrd input. they needs to be put together. just i dont want it to check the password. can you please help

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. Flow Overview The sign-up or sign-in process with the "bring your own screen" feature involves the following steps: 1. The PKCE flow is initiated to generate an authorization code. 2. This code is sent to the BYOS screen where the user can either sign up or sign in. 3. After the user completes the sign-up or sign-in, a backend verification of the code is performed. Edge Case Handling In the sign-up/sign-in screen, there is a specific edge case where you need to determine if the email address domain is associated with SSO login or a standard email/password flow. The challenge arises because the current flow checks the password, but you want to avoid this check in certain scenarios. To handle this, you can implement a conditional check based on the email domain before proceeding to validate the password. This way, you can present both the email and password inputs together while controlling the flow based on the email domain. Suggested Implementation You can use a conditional statement to check the email domain before validating the password. Here’s a general pattern you might consider:

const email = getEmailInput();
const password = getPasswordInput();
if (isSSODomain(email)) {
    // Proceed with SSO login flow without checking the password
} else {
    // Validate the password for normal email/password flow
    validatePassword(password);
}

In this code: •

getEmailInput()

retrieves the email input from the user. •

getPasswordInput()

retrieves the password input. •

isSSODomain(email)

checks if the email domain is associated with SSO. •

validatePassword(password)

is called only if the email domain does not match SSO. Conclusion By implementing this conditional check, you can effectively manage the sign-up/sign-in process while ensuring that the password validation is only performed when necessary. If you need further assistance or have more questions, feel free to ask!

Hi @Aksha Malik Thanks for sharing your flow details! This is a well-known use case in Descope and is fully supported natively no custom code needed. Use a Condition Block after the BYOS screen Even though your BYOS screen collects both email and password together, you can control what happens after the form is submitted by inserting a Condition block in the flow. The password field value simply won't be used if the flow routes the user to SSO instead. You can just follow these steps - Step 1 — BYOS Screen → User submits email + password (both fields present on screen, as required) Step 2 — Condition Block (add this right after the BYOS screen action): • If

tenant.enforceSSO

is

True

→ route to the SSO action (password is ignored entirely) • Else if

ssoEnabled

is

True

→ route to the SSO action • Else → route to the Email/Password authentication action (password is validated here)

@Akash Jivane hi i check in that way but still getting error, can you please check if condition is added correctly or not

Sure, let me check.

thankyou

I reviewed your updated flow JSON and found two issues causing the problem: 1. In your flow, the SSO branch of your Condition block is connected to a Redirect to URL step pointing to

{{device.location.origin}}/sso-login/ncm

, and it's opening in a new tab. Replace the Redirect to URL step with the built-in SSO action from the Descope flow builder. The SSO action handles the IdP redirect within the same flow context so the PKCE code exchange completes correctly. You can also pass

form.email

as a Login Hint inside the SSO action to pre-fill the email at the IdP side. 2. Your Condition block is currently set to check

tenant.enforceSSO

is True AND

ssoEnabled

is True. Because both must be true simultaneously, users whose email domain has SSO configured but not enforced will still fall through to email/password. Use OR logic — if either condition is met, route to SSO. better use as two separate branches.

can you check i changed condition flow stil getting same checking password. ref image attached also attached flow

Your flow logic is now correctly set up. The Condition block and the SSO action are both wired correctly. Wrong password or unknown user The flow is landing on Sign In / Password for

<mailto:amalik@nucompass.com|amalik@nucompass.com>

, which means both

tenant.enforceSSO

and

ssoEnabled

are evaluating to false. The

ssoEnabled

key works by checking whether any tenant in your Descope project has an SSO configuration with a matching email domain. Right now,

<http://nucompass.com|nucompass.com>

is not configured as an SSO domain for any tenant — so Descope falls back to password. Add the SSO domain to your tenant - 1. Go to Descope Console → Tenants 2. Select the relevant tenant 3. Go to Authentication Methods → SSO 4. Add

<http://nucompass.com|nucompass.com>

as an SSO domain Once saved,

ssoEnabled

will return

true

for any

@nucompass.com

email and the flow will route correctly to SSO. Let us know once you've added the domain!

okay let me check, thankyou

Have you configured the actual SSO provider (SAML or OIDC) under Authentication Methods → SSO inside that tenant ? Without a complete IdP configuration,

ssoEnabled

will still return false even if the domain is listed.

yes it is configured completely

For this flow this is not working right ?

yes

Can you try adding an email input field in your Login BYOS screen with

name="email"

and make sure it's not marked as

external-input

? The

ssoEnabled

key needs

form.email

to be populated to check the domain, and it looks like the email isn't being passed into the flow context from your Login screen. Let us know if that helps!

let me check

Great!