Clean up dormant Auth0 accounts and cut your monthly bill

Build me a cleanup console for trimming dormant Auth0 accounts before they inflate our monthly active user bill. This is an interactive triage and bulk action surface that I open when I want to run a cleanup sweep, not a scheduled report. The whole point is that I actually retire accounts from inside the app.

The main screen is a triage table of dormant accounts. At the top I pick an inactivity threshold of 90, 180, or 365 days. Use Auth0 Search Users to fetch accounts whose last login falls before that cutoff, with a Lucene range query against last_login and search_engine set to v3, in the shape last_login:{* TO 2026-05-16} where the date is computed from the threshold I picked. Each row shows email, connection, signup date, total logins, and days since last login. Sort by days since last login descending by default, so the most stale accounts are on top. Accounts that have never logged in at all will not match a last_login range query because the field is absent, so handle those deliberately rather than silently dropping them, either by querying for them separately or by clearly scoping the table to accounts that have logged in at least once.

Beside the table put a header tile with the current tenant monthly active user count from Get Active Users Count, and next to it a login and signup trend from Get Daily Stats over the trailing 30 days. This is the cost context for the sweep, so it should be visible while I work rather than buried on another page.

Let me filter the table by connection so federated enterprise accounts can be reviewed separately from database signups. There is no operation for listing tenant connections, so build the filter options from the connection values present in the loaded result set rather than trying to fetch a connection list.

Page based user search is capped at the first 1,000 results, so on a large tenant the table cannot simply page to the end. Handle this honestly: page through results with page and per_page up to that ceiling, tell me plainly when the result set is truncated, and push me toward narrowing the sweep with a longer threshold or a connection filter instead of pretending I am seeing everything.

I select rows and take bulk action from the table. Every selection must default to block rather than delete. Blocking uses Update User to set the blocked attribute, which retires the account quietly and is reversible. Deleting uses Delete User and is irreversible, so it sits behind a typed confirmation box where I have to type a confirmation phrase before it will run.

Before any delete is allowed, check each selected account with List User Roles. Any account that currently holds a role is excluded from the delete path entirely. Show a clear badge on those rows explaining why they cannot be deleted. They can still be blocked, but the delete action must be unavailable for them, not merely discouraged. Run this check as part of preparing the delete, so a role assigned after the table loaded is still caught.

Auth0 user ids embed the identity provider, in the shape auth0|66f1 or google-oauth2|1057, and must be URL encoded when used in path segments for the update, delete, and role lookup calls. Get this right or the write actions will fail on anything other than plain database users.

Track what happens during a session. Keep a running record of which accounts were blocked and which were deleted, with the email, connection, and days idle for each, and show it as a session panel so I can see what I have done so far. When I finish, a button posts a summary of that session to a Slack channel I choose using the Slack Bot Send a Message operation, listing what was blocked and what was deleted with counts, so the rest of the team has a record of the sweep. Persist the session record so the console still shows the history of past sweeps when I come back to it.

Bulk actions run over many accounts, so process them at a sensible pace and surface per row success and failure rather than failing the whole batch on one error. If an action fails, keep the row in the table with the error visible so I can retry it.