Finding the right inbox when there are thirty

An inbox carries three pieces of text you write, and they answer three different questions.

	What it answers	Form
Name	“which one is this?”	Required, a label
Description	“what is it for?”	Optional, one sentence
Tags	“which ones go together?”	Optional, shared across inboxes

Why a description is not a tag

The usage this product encourages — one inbox per suite, per branch, per pipeline — quickly fills the name column with feat/payment, feat/payment-2, smoke, smoke (old). You are then the only person who knows which is which.

A tag does not answer that: a tag exists to be shared by several inboxes and to filter. A description belongs to one inbox and only serves to recognise it.

It appears under the name in the table and under the title in the inbox view, and is edited in place in both. Clearing the field removes it.

Emoji are allowed, and that is not a nicety: 🔴 do not delete is spotted in a list faster than any wording.

The filter bar lives in the URL

Filters by field and operator, filters by tag, sorting: the whole state of the bar is in the page address. A filtered view can therefore be bookmarked, shared in a ticket, and comes back identical after a reload.

Renaming, deleting

Renaming happens inline, in the table as in the inbox view. Deletion exists one at a time and in bulk.

Deleting an inbox does not dissolve its consumption. What it received this month stays counted for the organization, and stays attributable to its name in the usage detail. This is deliberate: without it, deleting an inbox at the end of the month would erase the record of what it consumed.

What deletion takes with it

The inbox’s messages and their raw files, immediately. There is no recycle bin: a test inbox deleted by mistake is recreated in one gesture, whereas a recovery window would force us to keep messages longer than quotas-et-retention promises to purge them.