Auth0 support console for customers who cannot log in

Build an internal support console that my team opens whenever a customer says they cannot log in. It should put our Auth0 identity data and that customer's Zendesk tickets on one screen, so an agent never has to flip between two admin consoles to answer one question. It is a single main screen: a search box at the top, a result list, and a profile panel for whoever is selected.

Search. The search box accepts an email address or a partial name. If the input looks like a full email address, use Auth0 Get Users by Email for an exact match. Otherwise use Auth0 Search Users with Lucene query syntax and search_engine=v3, building a query across name and email such as name:"jane*" OR email:"jane*". Results show name, email, the connection they signed up with, last login, and a badge when the account is blocked or the email is unverified. Show a helpful empty state that suggests trying the full email address, since partial search does not always match.

Profile panel. Picking a result loads that person fresh with Auth0 Get User by id and shows: email plus verification state, blocked status, last login as both relative and exact time, total login count, the connection from their identities, account created date, and the raw user id with a copy button. Under that, list current two factor devices from Auth0 List User MFA Enrollments with the factor type, device name, enrollment date, and a remove button per device.

Activity timeline. Next to the identity data, render a plain English timeline of recent activity from Auth0 Get User Logs, grouped by day, newest first, showing time, decoded label, IP address, and browser or device where available. Decode the Auth0 type codes into readable labels rather than showing the raw codes: s is a successful login, f is a failed login, fp is a failed login with the wrong password, fu is a login attempt with an unknown email address, limit_wc means the account was temporarily blocked after too many failed attempts, scp is a successful password change, fcp is a failed password change, ss is a signup, and slo is a sign out. Any code you do not recognize renders as Other activity with the code shown in small text. Note that the logs endpoint uses checkpoint pagination: pass take and then from set to the id of the last item, and it ignores other parameters.

Support tickets. In the same profile panel, pull that customer's tickets from Zendesk Search Tickets matched on the same email address, using a query like type:ticket requester:<email>, defaulting to tickets that are not yet solved and sorting most recently updated first. Show subject, status, priority, requester, last update time, and a link that opens the ticket in Zendesk. If nothing comes back, say clearly that no tickets were found for that email address rather than showing an empty box, since the customer may use a different address in Zendesk.

Actions. The action buttons cover the fixes support actually makes, and every single one goes through a confirmation step first. The confirmation dialog names the customer, states exactly what is about to happen, and requires an explicit confirm before anything runs. The actions are: Unblock User to clear a brute force lockout; Update User to set blocked true or false when an agent needs to block or unblock manually; Create Password Change Ticket to generate a reset link the agent hands to the customer; Create Email Verification Ticket to resend verification; and Delete MFA Enrollment on a specific device so someone with a lost phone can re-enroll. When a ticket link comes back from the password change or email verification action, display the full link with a copy button and a note that it is single use and time limited.

Data handling rules to bake in. Auth0 user ids embed the identity provider, like auth0|66f1... or google-oauth2|1057..., and must be URL encoded in path segments as auth0%7C66f1... Mint the Auth0 Management API token once per handler run and reuse it for every call in that run, never once per request. Auth0 search indexes lag writes by a few seconds, so after any account changing action re-read the profile with Get User and refresh the two factor list and timeline directly, never by re-running Search Users, or the panel will show stale state.

Guardrails. Do not include account deletion anywhere in this app, not as a button, not behind a menu, and not as a handler. Support should never have that power from this console. Keep a Recent actions strip on screen that records every action taken in the app with timestamp, the customer email, the action, and whether it succeeded, persisted with the app so the team can see what has already been tried on an account before repeating it.

Polish. Enter runs the search, results are keyboard navigable, and panels show loading skeletons instead of jumping layout. Surface Auth0 and Zendesk errors in language an agent understands: a permission error should say the connection is missing a permission rather than printing a status code, and a rate limit should back off and retry quietly before showing anything.