Configuration: labels, stages and statuses

Clients → Configuration is the words your Protocol uses about your clients. There are three sets of them, they do different jobs, and this is the only screen that shows all three together.

The three vocabularies, and what each one drives

They are not interchangeable. A stage is where somebody is in your business; a label is anything else you want to say about them; a status is about one submission, not about the person.

Renaming is safe, and it reaches everybody

A rename in any of the three updates every client or entry already carrying it. Nothing is re-tagged and nothing is lost, because these are stored by identity rather than by their text. So renaming VIP to Inner circle is a cosmetic change and a safe one.

The thing to think about before renaming is your saved links and your habits, not your data.

Retiring, and why it is not deleting

Switching a label or a status to Deprecated takes it out of the pickers so nobody applies it again. Everyone already carrying it keeps it, it still shows on their record, and it still works as a filter. That is what you want for a campaign that ended: the history stays readable and the vocabulary stops growing.

The card on the Configuration tab marks those rows Retired. It is the same state under a different word.

Merging two labels that mean the same thing

Anything holding an API key can create a label just by using its name, so a tenant collects near duplicates without anybody deciding to: VIP, vip clients, V.I.P.. Merge is how you fold them back into one.

Open the label editor, find the row you want rid of, and use the merge control on it. You pick which label it goes into, and Protocol tells you how many clients are about to move. Every client tagged with the old one comes out tagged with the one you kept, and the old label is then removed.

Nothing loses a tag. That is the whole difference between merging and deleting, and it is why merge is the right tool for a duplicate and delete is not.

What you can actually delete

• Labels: yes. Delete removes the label from every client carrying it, and the confirmation says how many that is. If those tags are worth keeping, merge instead: the dialog says so too.
• Progress entry statuses: no. Retire them instead. An entry stamped with a status you removed would have nowhere to sit.
• Lifecycle stages: yes, with a guard. Deleting a stage nobody is in is immediate. Deleting one clients are sitting in is refused, and Protocol tells you what is using it. Moving those clients is a client-by-client job today; the dialog suggests a destination but does not do the move for you.

Retiring is still the better move in most cases. Delete when a label was a mistake; retire when it was real and is finished.

Ordering

Stages are a sequence and the order is the board. The up and down arrows in the stage editor set the left-to-right order of the columns on your Pipeline, so put them in the order somebody actually moves through.

Labels and statuses have arrows too, and there they only set the order the options appear in the pickers. Nothing downstream reads it as a progression.

Labels

The Labels card lists your whole vocabulary, retired ones included, with a count of how many clients carry each. That count is the one number that tells you whether a label is worth keeping.

Edit opens the label editor, where you add, rename, recolour, retire, merge and delete. Each change is saved as you make it rather than on a Save button, which matters here: your integrations are writing to the same list, and a save that wrote the whole list back would wipe anything they created while you had the dialog open.

Everything else about labels, including tagging clients and filtering the roster by them, is in Client labels.

Lifecycle stages

The Pipeline board is made of these, in this order. If you have none, the board shows a single Unstaged column and nothing else, which is what a new tenant sees.

The editor adds a stage by name, and each row carries a colour, an editable name, the reorder arrows, and a Terminal switch.

Terminal marks a stage as an ending: Churned, Cancelled, Did not start. It is not a visual difference. Your dashboard’s churn count is the number of clients sitting in a terminal stage, so it is worth setting on the stages that mean somebody has left, and worth leaving off everything else. With no terminal stage, that count is always zero.

Stage edits save as you make them rather than on a Save button.

Progress entry statuses

These are the buckets a check-in moves through after it arrives: something like Pending, Processing, Done, Needs follow-up. They are your words, not ours, and they are what the segment chips on Check-ins → All submissions are built from.

Mostly they are set for you. An automation drafting a report moves an entry along as it drafts and as you review, which is what makes them useful as a worklist rather than as decoration. You can also set one by hand on any entry, or on a batch of them.

If you have no statuses at all, submissions sit on Protocol’s own internal Pending and the segment row is empty.

The card shows a dash rather than a count in each row: nothing counts entries per status, and a zero there would read as “none”, which would usually be wrong.

Good to know

• These are tenant-wide. Everybody on your team sees and uses the same three vocabularies. There is no private set, and clients never see any of them.
• Anything connected to your API can create labels, so near duplicates accumulate. This is the screen where you tidy that up: merge the ones that mean the same thing, rename the keepers, retire the rest.
• A retired status still filters. An entry stranded on a status you retired is still reachable, which is the whole reason retiring beats deleting.

Related: Client labels, Finding a client for the filters these feed, and Progress reports for what moves an entry between statuses.