Admin Panel Checklist

An Internal Button Is Still Production Authority

An admin panel often begins with a customer waiting. A job is stuck, an invitation went to the wrong address, or an account needs a correction. The founder opens a console, changes a row, and gets the customer moving. After the third time, the shortcut becomes a button.

The smaller audience does not make that button harmless. A control that changes a plan, replays a job, issues a refund, reveals customer data, or alters ownership is a production capability. It can bypass the rules that protect the ordinary product, and its mistakes are unusually hard for customers to understand.

Review one action at a time. The question is not whether the panel has enough features. It is whether this particular support outcome can be reached by a narrow, authorized, inspectable path—and whether the path should exist at all.

Give the Action a Contract

Begin with the customer outcome: “retry one accepted report import” is more useful than “manage jobs.” Name the object, its current state, the allowed destination, and the conditions that must still be true when the action runs. An admin control should call an explicit application operation, not grant a friendly interface to arbitrary database writes.

For the proposed action, write down:

• the customer problem it resolves and how often that problem occurs;
• the exact object and state transition it is allowed to affect;
• the preconditions that make the transition valid;
• synchronous and background side effects, including messages and billing;
• the largest plausible blast radius;
• whether repetition is safe, detectable, or dangerous; and
• the manual or product path that would remain if the control disappeared.

This contract usually makes the first scope cut. A tool that can retry one failed import does not need the ability to assign arbitrary job states. A refund control does not need a general balance editor. If the need is rare, a reviewed command or runbook may be enough—but it should invoke the same constrained operation and leave the same evidence. A raw SQL console is broad authority, not a minimal admin panel.

Separate Looking From Acting

Most support work begins with understanding. Build the read path before the write path, and show only what changes the diagnosis: product state, recent transitions, relevant delivery attempts, and opaque references that join to authorized logs. Do not copy complete customer records into an internal screen merely because they are available.

Treat sensitive reveals as actions of their own. Mask data by default, require a support reason when a reveal is justified, keep the exposure narrow, and record that it happened. Do not make impersonation the default way to understand a user’s experience. Prefer a safe support view; if impersonation is unavoidable, make the session conspicuous, bounded, attributable, and unable to conceal who actually acted.

Seeing an action in the interface must never confer permission to perform it. The server should authenticate the operator and authorize the requested operation against the target object on every request. Deny access when identity, role, account scope, or a required fact is absent. A solo founder may be the only operator, but should still use a unique identity, strong account protection, and credentials that can be revoked without taking the customer product down.

Show the Consequence Before Committing It

The confirmation screen should say what the system is about to do, not merely ask whether the operator is sure. Show the customer or workspace, target object, current state, proposed state, important side effects, and whether recovery is possible. For a destructive or unusually sensitive action, require fresh authentication or another approval appropriate to the harm.

Generate the preview from trusted server state. When the operator confirms, load and authorize the target again, then verify the same preconditions under the write’s concurrency boundary. Otherwise the panel can display one object and act on a changed one, or apply a once-valid transition after another process has moved the state.

Plan for double submission, a lost response, and a browser retry. Use an idempotency key or an operation record when an action must happen at most once. If repetition is valid, make the result explicit. “Request failed” is not enough when the server may already have issued the refund or started the job.

Design Recovery With the Action

Choose the recovery path before exposing the button. A reversible change can retain the prior value and offer a bounded undo. A restartable workflow can preserve its durable state and resume from a known transition. An irreversible action may need a delay, a narrowly scoped approval, or removal from the panel altogether.

Recovery should restore a valid product state, not merely reverse a database field. If changing an account owner also sends mail, updates permissions, and transfers scheduled work, changing the owner field back is not a complete undo. List the side effects and decide which ones must be compensated, preserved, or explained to the customer.

For every attempt, record enough to reconstruct the decision:

• when the request and completion occurred;
• which human identity requested it and which service executed it;
• the action, target, and relevant before-and-after state;
• the support reason or case reference;
• the precondition or object version used;
• the result, failure reason, and correlation identifier; and
• any recovery or customer communication that followed.

Audit records need protection from casual modification and deletion. They also need restraint: access tokens, credentials, raw uploaded content, full payment data, and unnecessary personal information do not become safer because they are in an audit log.

Copyable Admin-Action Review

Complete this review for one action, not for the panel as a whole. Replace intention with evidence from an authorization test, preview, audit query, recovery exercise, or representative production-safe trial.

# Admin action review: [one customer outcome]

Owner:
Review date:
Support problem and observed frequency:
Why a product flow or runbook is insufficient:
Action to add, retain, narrow, or remove:

## Contract
Target object and customer scope:
Allowed current state:
Allowed transition or operation:
Preconditions checked at execution:
Side effects:
Largest plausible blast radius:
Behavior on repeat or lost response:

## Access and data
Who may find the action:
Who may execute it:
Server-side permission and object-scope check:
Session or fresh-authentication requirement:
Customer data shown by default:
Sensitive data reveal, reason, and record:
Denied-access test:

## Preview and execution
Trusted fields shown before confirmation:
Exact consequence the operator confirms:
Concurrency or stale-state protection:
Idempotency or operation identifier:
Success evidence:
Partial-failure behavior:

## Audit and recovery
Identity, target, reason, time, before, after, and result recorded:
Sensitive fields deliberately excluded from the record:
Prior state or durable checkpoint preserved:
Undo, compensation, or safe fallback:
Recovery exercise and observed result:
Customer communication trigger:

## Product boundary
Manual path if the control is unavailable:
Usage or failure signal to review:
Condition for moving this into the customer product:
Condition for narrowing or deleting the action:
Decision: do not build | build | retain | narrow | remove

Worked Review: Retry, Do Not Rewrite History

A reporting product accepts a customer file and starts an import. One import exhausts its automatic retries after a temporary storage failure. The founder’s first admin design has two fields—job ID and status—and a button labeled Set complete. It would clear the support ticket quickly. It would also create a lie: no report has been produced, downstream notifications may not have run, and the ordinary state machine has been bypassed.

The useful operation is narrower: Retry failed import. It appears only for a job in the terminal failed state whose source is still within its valid retention window. The server verifies the founder’s identity, permission, workspace scope, job state, and source availability. The preview names the workspace and job, shows the last completed transition and failure category, and explains that a new processing attempt may produce a report and customer notification.

On confirmation, the service creates one operation record with an idempotency key. Under the same concurrency control used by the worker, it moves the job from failed to queued and links the new attempt to the original history. A second click returns the existing operation rather than starting another import. If the source has expired or the job has already moved, the action refuses to run and says why.

The audit entry records the founder, workspace reference, job reference, support reason, prior state, operation identifier, and result. It does not copy the file name, file contents, customer email, or storage credentials. Recovery can cancel a still-queued attempt; once processing has produced downstream effects, the runbook describes how to contain or compensate those effects rather than pretending that setting the old status back is an undo.

The review also sets a product boundary. If customers repeatedly need the retry after recoverable failures, the capability belongs in the normal product with appropriate limits and feedback. If the action is never used after the underlying defect is repaired, it should be removed. The admin panel is not where missing product behavior goes to live forever.

Keep the Surface Smaller Than the Responsibility

Review admin-action use alongside support work. An action that appears in every customer conversation may be a concealed workflow. One that is never used may be stale authority. One that often fails may be modeling an invalid state transition. Move repeated, safe customer work into the product; repair recurring defects; and delete controls whose original incident has passed.

The review is complete when one real support outcome has a narrow contract, server-enforced authority, an honest preview, a recorded execution, and a recovery path proportionate to its harm. The goal is not a powerful control room. It is the least internal authority you can operate safely while customers depend on you.