Login & Account Access covers the sign-in experience end to end — what the platform checks behind the "Continue" button, how MFA and lockout work, what to do when you can't get in, and why you sometimes get logged out unexpectedly.

Overview

Every sign-in, whether by password, SSO, or OTP, runs through the same sequence of checks before a session is created: account lookup, credential verification, account state, login restriction, password flags, and MFA. Understanding that order makes every login error message easy to place — each one corresponds to a specific step failing. This page also covers the two account-access dead ends users hit most — a locked account and a forgotten password — and rounds up the most common causes of an unexpected logout.

Use Cases

• Help a user understand exactly why their login failed from the error message alone.

• Explain to a user why the login page still asks for a username after switching to OTP.

• Walk a locked-out user through getting back in, with or without admin help.

• Diagnose an unexpected logout by ruling causes in or out.

• Distinguish a permissions problem ("I'm logged in but can't see a screen") from a login problem.

How Login Works

The login page — "Log in to your account" — shows a Username and Password form with Continue, a Forgot password? link, and one button per enabled SSO method, labeled with each provider's configured button text. SSO buttons redirect to the identity provider and back.

For password login, the platform runs these checks in order:

1. Account lookup by username — usernames are case-insensitive.

2. Password check against the stored hash. A wrong password counts toward lockout.

3. Account state — only Active accounts may sign in; Locked, Disabled, Dormant, and Deleted each fail with their own message.

4. Login Restriction — if the sign-in method has a user-criteria rule, the user must match it, or the login fails with "User criteria check failed".

5. Password flags — an expired password or a required change sends the user to Update Password before anything else.

6. MFA — if the method has MFA configured, the user is sent to Verify OTP.

7. Otherwise, a session is created, the session cookie is set, and the user lands on the page they originally requested. A successful login also clears the failed-attempt counter and is recorded in the activity log.

Account Lockout

Wrong-password attempts are counted per user account — attempts against a username that doesn't exist lock nothing. By default 5 failed attempts lock the account; each sign-in method can override the limit, and can optionally show "Remaining Attempts: N" with each failure. The counter can also reset itself after a quiet period if the method configures a reset duration; without one, the count persists until a successful login or an unlock clears it.

When the limit is reached, the account's State flips to Locked and login fails with "User is temporarily locked". Unlock happens one of two ways:

• Auto-unlock: if a lockout duration is configured, a one-shot timer flips the account back to Active exactly that many minutes after the lock.

• Manual: an admin sets the user's State back to Active, which also clears the failed-attempt counter.

If no lockout duration is configured, there is no auto-unlock — the account stays locked until an admin intervenes. Locking is also recorded in the audit log and user activity report.

Multi-Factor Authentication (Verify OTP)

When the sign-in method has MFA configured, after credentials pass the user is taken to Verify OTP: "Enter 6-digit OTP", with Resend OTP and Back to Login. MFA can use OTP codes or push approval, is configured per sign-in method by an admin, and the code is generated and delivered by an admin-chosen automation — the shipped screen expects a 6-digit code. This is a second factor added after another sign-in method already checked credentials — it's different from choosing OTP as the sign-in method itself, covered below.

All of the following defaults are configurable per sign-in method:

• The code lives about 5 minutes. Resend OTP issues a fresh code and restarts the window; an expired session shows "Invalid session" / "Request activity has timed out. Please log back in."

• Wrong codes are limited. Each wrong code shows "Invalid OTP" with remaining attempts; by default 5 failed codes in a 5-minute window invalidates the OTP session and temporarily blocks MFA for that user for 30 minutes.

• Requesting and resending are rate-limited too. By default at most 5 OTP requests and 5 resends per 5-minute window; exceeding either blocks the user for 30 minutes.

• The MFA block is temporary and separate from account lockout — it expires on its own and doesn't change the account's State.

• Codes are single-use — a correct code consumes the session and can't be replayed.

MFA can be required separately for login, forgot-password, and profile-update flows, each with its own configuration on the sign-in method.

Signing In with OTP as a Method

The identifier box on the login page is fixed to "Username" and doesn't change based on which sign-in method is active. OTP is a "password-family" method: it shows the same Username step as password login and simply replaces the password with a one-time code. A person signing in with OTP enters their username first; the platform looks up that account and sends the code to the phone or email already on that user's profile. The phone number is never typed on the login page — it comes from the user record.

To have people sign in with a phone number instead, one of two approaches is supported:

1. Make the phone number the username. Provision or sync each user so their username is their phone number — the label still reads "Username", but it works because the phone number is the username.

2. Build a Custom Workflow identity provider. This runs a login flow you build yourself, including a custom login screen that can show a real Phone number field, plus an authentication automation that verifies it.

Forgot Password

Click Forgot password? on the login page. On "Forgot your password", enter the username and click Send Reset Link. The next screen — "Check your email" — confirms the reset instructions were sent to the registered email, with a Resend email option available after a countdown.

• The reset link expires after about 5 minutes and is single-use, consumed the moment a reset succeeds. An expired or used link shows "Invalid Link".

• If the new password fails strength or reuse rules, the error is shown but the link isn't consumed — fix the password and retry within the 5 minutes.

• A successful reset signs the user out everywhere; the new password works immediately without a forced follow-up change.

• There's a limit of 5 reset requests per rolling 24 hours per username, starting from the first request.

• For security, the screen looks identical whether or not the username exists or has an email on file — if no email arrives, ask an admin to use Reset Password instead.

• If the sign-in method has MFA configured for password resets, there's no email at all — the user verifies an OTP first and is taken straight to a reset page.

Why Login Fails

The exact message tells you the cause:

• "Invalid username or password" — wrong credentials.

• "User is temporarily locked" — too many failed attempts (5 by default).

• "User is disabled" / "User is dormant" / "User is deleted" — the account state blocks login; an admin must change it.

• "User criteria check failed" — a Login Restriction rule excludes this user.

• "Invalid OTP" / "Number of retries exceeded" / "Invalid session" — MFA problems.

• "SSO login failed" — the identity provider handshake failed; check the SSO configuration with an admin. "This login request has already been used" means a stale SSO redirect was replayed — start over from the login page.

Failed logins are captured in the user activity report with source IP and can trigger tenant webhooks, so admins can monitor brute-force patterns.

Why Was I Logged Out?

The usual causes, in rough order of likelihood:

• Inactivity — sessions last the sign-in method's Session Expiry Time (24 hours if unset), but activity quietly renews them, so in practice a user expires only after being away for the full window.

• An admin reset the password or deleted the account — both end every session immediately.

• The user reset their own password via the forgot-password link — also ends every session.

• Restrict Multiple Sessions is on and the user (or someone with their credentials) signed in elsewhere — the new login evicts all older sessions in real time.

• Single Tab Session is on and the user opened the platform in a second tab.

• Perpetual Login isn't enabled and the session simply expired.

Notes

A few habits make login issues faster to resolve:

• Read the exact error message before troubleshooting — each one maps to a specific step in the login sequence.

• Distinguish a missing screen or button (a permissions issue) from a login failure — they have different fixes.

• Point users to Forgot Password before reaching for an admin reset, unless the account has no email on file.

• Set a lockout duration if you don't want every locked account to need manual admin attention.

• Remember OTP as a sign-in method still asks for Username — a phone-number field on the login page requires a Custom Workflow identity provider.

Most login problems trace back to one of a handful of well-defined checks — knowing the sequence turns a confusing error into a quick diagnosis.