Choose how you sign in

Sign in with a password, an emailed code or a texted code, with the destination stated on screen instead of guessed at.

What it is

A custom sign-in flow with four steps: identify yourself, choose a verification method, enter the secret, and — where enabled — complete a second factor. The available methods are read from the auth provider at runtime rather than hardcoded, so the picker only ever offers what the account actually supports, and unusual states are handed back to the provider's own screens rather than reimplemented.

Also called: login options · email code or text · password or code · where did the code go

See it
Choose how you sign in
Area
Platform & Admin
Group
Sign-in
System
Multi-Tenancy & Identity
Solves
3 named problems
01Step 1 takes the email and asks the provider which first factors this account supports.
02If only one method is available it is started silently; if several are, the picker is shown with the destination for each.
03Codes are sent to the specific address or number the provider named, and the screen says which one.
The method step: three stacked options — Password, Email me a code, Text me a code — each with its destination underneath. src/components/auth/BrandedSignIn.tsx. Sample data — no customer information appears here.
How it works
  1. 1Step 1 takes the email and asks the provider which first factors this account supports.
  2. 2If only one method is available it is started silently; if several are, the picker is shown with the destination for each.
  3. 3Codes are sent to the specific address or number the provider named, and the screen says which one.
  4. 4The method that succeeds is remembered for next time.
  5. 5If the account requires a second factor, the flow moves to the authenticator, backup code or texted code step.
  6. 6States the custom flow doesn't own — needs a new password, provider trust checks — fall back to the provider's own component instead of dead-ending.
Why we built it

The header names the problem it replaced: the prebuilt component 'chooses a verification strategy on the user's behalf and states the destination only in passing, so people were landing on enter your code with no idea whether to check email or their phone (Keith, 08-12). It also has no memory: someone who prefers a text has to hunt for use another method on every single sign-in.' The runtime factor read is flagged as deliberate — 'supportedFirstFactors is read at runtime, never hardcoded' — and verified against each environment rather than assumed. The fallback path exists so a rare provider state never becomes a locked-out user.

The problem
  • Users couldn't tell whether a verification code went to email or phone.
  • The preferred method had to be re-selected on every sign-in.
  • A hardcoded method list breaks the moment the auth configuration changes.
Sound familiar?
What you get
The screen always says where the code was sent.
Your preferred method is the default next time.
The picker never offers a method that can't actually work.
What's inside

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →