Someone cannot sign in. Here is the whole job

A customer writes in. They cannot get into their account, and the message says nothing more useful than that. This is the order to work in: find them, read the page, work out which of four ordinary problems this is, then use the one button that fixes it. You can follow it while they are still on the call.

Find the person

End-users belong to an Application, not to your workspace. Open the Application they are a customer of, then the End-users tab. The same human signed up to two of your Applications is two separate end-users, so check you are in the right product before you decide somebody does not exist.

The search box reads Search by email, and it is usually all you need. Paste the address from the ticket and press Apply. Two filters sit next to it, each starting at any:

• Verified: any, which narrows to verified only or unverified only.
• Subscription: any, which narrows to one of PENDING, ACTIVE, PAST_DUE, CANCELED and EXPIRED.

When anything is set, a filtered (clear) link appears next to the button. Use it before you conclude the account is missing: a stale filter is the usual reason a real customer returns no rows. Each row ends in Details, which is where the rest of this guide happens.

Read their page

The detail screen is a tab strip over one person. Each tab answers a different question, and only one of them is about sign-in.

Subscriptions and Credits are billing reads. Without that access they are not offered at all, rather than offered and refused.

Read the four tiles before you touch anything. Plan, Devices, Credits and Sign-in each link to the tab where you can act. A tile showing a dash rather than a number means the read failed, not that the answer is zero.

Tell the four cases apart

“I cannot sign in” is four problems with four fixes. Each has a signal on the page, so decide before you act.

A locked account

The Sign-in tile reads Locked and its footer gives the time the lock expires. On the Security tab the Sign-in health card says the same thing under Lockout, as a badge reading locked until that time, or the word none.

That card states where the state comes from: the lockout lives in the cache store behind the brute-force limiter, not as a column on the end-user row. So it is per Application, keyed by the Application and the email, and unlocking one product does not unlock another. The Failed sign-in attempts figure is shown against its threshold, as something of ten, because a bare count answers nothing. Once the lock is in force that counter has been consumed, so the panel shows the threshold with a greater-or-equal sign rather than an exact number it does not have.

An unverified email

The list column reads pending instead of verified, and the profile card on Overview carries an unverified badge next to the address. There is a second, quieter tell: the Resend verification button only appears on the support bar when the address is unverified. If you cannot see it, that is not the problem.

A forgotten password

This one has no positive signal, which is why you check the others first. Not locked, verified, devices healthy, leaves the password. The panel tells you if the premise is wrong: a reset to an account with no password is refused, saying they sign in with OAuth or a magic link and that a reset would strand them on a form they cannot complete.

A device refusing them

The Devices tile turns amber and its footer counts the blocked machines, for example four active of six known and one blocked. The Devices tab shows each machine as ACTIVE, RELEASED or BLOCKED, and a blocked row carries the reason an operator gave. Devices appear only when the Application sends a fingerprint at sign-in, so an empty list without device binding is normal.

The five support actions

They sit in one row on Overview, under Support actions. Each is a single call, each reports what actually happened rather than that it was attempted, and each is recorded in the activity trail with your operator id.

1. Unlock account. Clears the lock and the failure counter for this end-user in this Application. It does not touch their sessions. Running it on an account that was never locked is a no-op, and the banner says so in as many words: nothing to clear, and whatever is stopping them, it is not the lockout. The same action appears on the Security tab as Clear lockout.
2. Resend verification. Only offered when the address is unverified. Mints a fresh verification token and sends the email again through the Application's configured transport, the same path sign-up uses. The dialog has a Reason field, optional, recorded in the activity trail.
3. Send password reset. Starts the same reset their own forgot-password link starts. The token goes to them and never to you. The Reason field here is required, and submitting without one is refused with “say why you are sending a reset, it goes in the audit trail”.
4. Reset devices. Frees every active device slot and revokes the sessions minted on those machines, so the next sign-in from any machine is admitted. Blocked devices are deliberately left blocked, and the banner tells you how many it skipped so a short count never looks like a broken feature. On the Devices tab the same thing is labelled Release all.
5. Sign out everywhere. Revokes every live session. Access tokens already issued keep working until they expire; what this stops is new ones being obtained. The banner reports the count, and says zero honestly when nothing was open.

Only the two that put mail in an inbox ask you for a reason; the other three record the action and your operator id with no free text. Read the banner afterwards either way. It separates sent from minted-but-not-sent, and a mail that could not be delivered points you at Email and Delivery rather than back at the customer.

What not to do

• Do not go looking for their password. There is nowhere to read one. Neither mail returns its raw token to the operator, so the reset reaches the person rather than the person who pressed the button, and the data export excludes password hashes, token hashes and MFA secrets.
• Do not edit a subscription to fake a fix. Granting one is for a sale with no payment provider behind it, an invoiced deal, a comped account, a migration, and the panel makes you write a note before it will do it. Reaching for it because somebody cannot sign in records a commercial decision that never happened, and it does not let them in anyway.
• Erasure is not a support action. It lives on its own tab for that reason. Erase (GDPR) is restricted to the workspace owner, deletes the personal data and credentials, tombstones the account so they can never sign in again, and cannot be undone. Financial records are retained but anonymized. If your role is not owner, the panel says so rather than offering the button.

What the customer sees

Worth knowing before you tell them what to expect: two of these send mail and three send nothing.

• Unlock account. No email. Nothing visibly changes at their end. They simply try again and are let through. Tell them to retry now.
• Resend verification. The verification email arrives again, with the same link and lifetime sign-up would have given them.
• Send password reset. An ordinary reset email, identical to the one their own forgot-password link produces. It does not yet say that support started it, which is why the panel warns you that at their inbox this looks the same as somebody who got into your panel. Say on the call that you are sending it.
• Reset devices. They are signed out on the machines that were released, and their next sign-in from any machine is accepted. A machine you previously blocked still refuses them.
• Sign out everywhere. They are signed out and have to sign in again. An access token already in flight keeps working until it expires, so the cut-off is not always instant.

Both emails go to the address on the account. If the customer is writing in from a different one, you have a different ticket: email is immutable on an end-user by design.

Where next

The same job is on video in the guides, if you would rather watch somebody do it once before you do it on a live ticket. For the rest of what changed in this release, see upgrading to 2.2.0.