Back in Stock Admin UI Implementation Guide

Without an Admin Screen, the Alert System Can't Be Operated

However carefully the delivery system is built, operations don't work without a screen to see what it's doing. When someone writes in to say their alert never arrived, there's no way to find out where it stalled, so the question goes to an engineer and everyone waits for a log check. Do that one enquiry at a time and support stops functioning entirely.

This article sets out what the admin screen for restock alerts needs to hold. The components haven't been built yet, so read this as a requirements write-up done before starting rather than a tour of finished work. The screen is designed as a tool the operations team opens every day, not as a developer console.

Separate the Screen for Looking From the Screen for Acting

Cramming both into one page invites mistakes

Put the screen for spotting problems and the screen for triggering retries in the same place, and someone who opened it just to check will end up pressing an action button. That's especially likely when a backlog of alerts has built up and people are moving quickly.

So split them: one screen shows the overall situation, another narrows down to specific alerts and acts on them. The first answers "what is happening right now" and nothing else. Building a path through the day's work where nobody has to hesitate is what decides the quality of this screen.

Detail views should read in chronological order

When you open a single alert, four things need to be visible in time order: which item it was for, what state it's in now, what caused the failure, and how many times it has been retried. Lay those out chronologically and the situation explains itself.

What operations staff usually want first isn't why it failed but what to do next to fix it. Show the cause and the corresponding action together. Raw developer-level records can sit collapsed underneath, which keeps the page readable without giving up the ability to dig in.

The top two are screens for finding things out; the bottom two are for changing things, plus the record of those changes. Keeping the roles unmixed is what reduces accidental actions while someone is just checking.

Guardrails So Retrying Doesn't Cause an Incident

Show how many messages will go out, before they do

Retrying is a genuinely useful feature, but get the filter wrong and a bulk retry floods people with duplicate alerts. Once sent, they can't be recalled, so the stopping mechanism has to sit before execution.

In practice that means three things: display how many alerts the action covers, insert one confirmation step, and cap how many can be processed in a single run. Those three catch almost every operational mistake. People rush exactly when they're busiest, so "make it harder to press" belongs in the spec from the start.

State when a settings change takes effect

Settings like send intervals and daily caps directly change delivery outcomes. Yet if the screen is nothing but a row of number fields, there's no way to tell whether a change applies immediately or from the next run.

So the settings screen should state when changes take effect and what they apply to. Add a way to see the before and after values side by side. If changing a setting is an opaque action, nobody can trace the cause when something goes wrong, so intent and result both need to stay visible afterwards.

Split Visibility of Personal Data by Role

Masked by default, full view only when needed

The admin screen handles alert recipients, which means user contact details appear on it. Show them all in full with no restriction and simply opening the page puts you in front of personal data. Mask them by default, and allow the full view only for a limited role.

Incident response is also exactly when information tends to escape, through screen sharing or a quick photo of a monitor. Rather than relying on staff to remember the rules under pressure, limit what the screen can display at all. Enforcing it in the system is more reliable in practice.

Masked as standard, full view only when there's a reason — and the viewing itself gets recorded too.

Three roles, plus a record of every action

Three permission levels are enough to work with: people who only look, people who also retry and pause, and people who can change settings and email content. Simply not handing everyone every permission narrows the blast radius of a mistake considerably.

On top of that, record who changed what and when. Unexpected or mistaken actions become detectable, and you can explain what happened afterwards. For an admin screen, getting this governance layer in place matters more than adding features. Leave it weak while operations grow and rebuilding it later becomes a real project.

Add the Outcome Numbers After It's Running

Don't publish figures you can't produce yet

Since the alert system itself hasn't been built, there are no real figures for revenue attributed to alerts or for how many recipients went on to buy. The screen design doesn't assume those will sit there as current performance. They're candidates for future measurement.

Not declaring results before building keeps both readers and the operations team from drawing the wrong conclusion. Once implementation progresses, the actual numbers can be added as they become available.

Decide the order in which metrics get added

When measurement starts, begin with the delivery figures themselves: how many sent, how many failed, and the breakdown of failure causes. Once those are stable, widen out to who opened the alert, who moved through to the product page, and who bought.

Try to measure everything at once and you lose the ability to tell whether a number is missing or merely wrong. Expanding one step at a time, confirming each, produces figures you can actually trust. Setting that order also gives you the order in which to build the screens.

Summary

The admin screen isn't there to look tidy; it's the foundation that keeps operations safe. Separate looking from acting, put guardrails on retries, split personal data visibility by role, record every action, and resist placing numbers you can't produce yet. Settle those five and the implementation phase can proceed without quality slipping.