Data browser

Summary#

The console has no raw table browser and no SQL box. Record inspection is spread across purpose-built screens, each of which reads one kind of record and shows the fields that screen needs. This page maps every record type to the screen that displays it, gives the order to work through when tracing one customer, and sets out the handling rules that apply because every one of these screens shows real personal data.

Purpose#

Support work is nearly always the same shape: a customer says something did not happen, and you need to find out what the system actually recorded. That means crossing several stores in one sitting, because a single incident leaves traces in usage counters, the activity log, the telemetry rollup and sometimes the error tables.

A general-purpose data browser was not built, for a good reason. An arbitrary query tool over production would show fields no support question needs, could not be audited meaningfully, and would make a mistyped filter dangerous. Narrow screens over specific records are slower to build and much safer to operate.

Requirements#

• An active admin session. See Getting admin access.
• MONITOR_DB bound for everything except Messages and Bug Reports, which read Supabase directly from the browser.
• The customer's email address. Nearly every lookup is keyed on it.

Permissions#

Every screen listed here is readable by both admin and owner. Reads are never role-gated. The mutations reachable from these screens are owner-only and are documented on their own pages.

Reads are also not audited. Nothing records that you opened a customer's record or exported the subscriber list. See Audit log.

Navigation Path#

There is no single entry point. Start from the record you need:

Admin console → Operations → Customers for one customer, everything at once.

Where each record lives#

Anything not in that table is not visible from the console. Saved results, report content, generated articles and result payloads are not exposed to admins at all.

Step-by-Step Guide#

Trace one customer end to end#

Work in this order. Each step narrows the next.

1. Customers. Type the address into customer@example.com and press Load, or press Enter. This is the single richest view: plan, quota, used and remaining, the AI-versus-tool split, suspension state, connected social channels, team members against the seat cap, the billing source, and the recent admin actions taken on that account. Full detail in Customer lookup and billing.
2. Run Log. Put the same address in customer email and press Search. This is the per-event timeline: what they ran, when, through which module, and whether it succeeded. See Run inspection.
3. Workflow Failures. Search the address. If a multi-step workflow broke for them, the failing step, their input and the raw error are here. See Error log and resolution.
4. System Health. If the same tool is failing for everyone, the Tool health table and Grouped issues will show it. That converts a single complaint into a platform incident. See Metrics and usage analytics.
5. Usage & Activity. Confirms the monthly counters that drive billing, and lets you compare against other customers on the same plan.

Find a customer when you only have a fragment#

1. Select Subscribers.
2. Type any part of the email or name into Search by email or name....
3. Narrow with the plan and status selects if needed.
4. Press View on the row. That jumps to the Customers screen with the address filled in and loaded.

Inspect a setting#

Select Config. The Configuration table lists every key with its value, the time it changed and who changed it. It is the only place a raw stored value is shown verbatim, and it is unbounded, so it is also the closest thing the console has to a table view. Reading it is safe. Writing to it is owner-only and takes effect platform-wide. See Runtime configuration.

Export#

Four screens export CSV: Subscribers, Usage & Activity, Run Log, and the audit log on System Health. Messages and Bug Reports export too. Every export is generated in the browser from rows already loaded, so an export is a snapshot of what is on screen, not a full table dump. Filter to what you need before exporting.

Handling rules#

These screens show live personal data belonging to paying customers. Treat them accordingly.

• Look up only what the request needs. Reads are not audited, which makes the discipline yours to keep rather than the system's to enforce.
• Exports leave the platform. A CSV lands in the browser's download folder and is outside every control the product has. Delete it when finished.
• Do not paste customer data into third-party tools. That includes translation, spreadsheet and AI services.
• Treat a workflow failure's email as unverified. Those rows are written by an unauthenticated endpoint called from the customer's browser. Confirm the address in the Run Log or on the Customers screen before acting on it.
• Messages and Bug Reports are gated in the browser only. Those two screens query Supabase directly, and the policies on those tables permit any authenticated user to read and delete rows. Deletions there are permanent and unaudited. See What the admin console cannot do yet.

Troubleshooting#

FAQs#

Is there a way to run an arbitrary query? Not from the console. Direct database access is a developer path, outside the admin console entirely, and is not documented here.

Can I see the contents of a customer's saved report? No. The console shows that a run happened, its tool, its status and its time. The result payload is never exposed to an admin.

Can I delete a customer's data? No. There is no account deletion or data export endpoint in the console. Requests of that kind have to be handled outside it. See What the admin console cannot do yet.

Does the customer know when I look at their record? No. Reads produce no notification and no audit row.

Which screen is authoritative for billing questions? The Customers screen for plan, quota and usage, because those are the values the worker enforces. The Billing card tells you where the plan came from, and reads Stripe live for the subscription itself.

Why do two screens disagree about a plan? Usage counters carry the plan recorded at the time of the run, while the customer record resolves the plan as it is now. A mid-month upgrade produces exactly that difference, and both numbers are correct for what they describe.