Tags

Tags are internal. They are your team's shorthand, put on a verification or on the person behind it, and the applicant never sees them. Their point is that you can filter by them afterwards, which is what an unfilterable free-text note can never give you.

Where they go

On a verification, a tag describes that attempt. On a person, it stays with them across every attempt they make, which is what you want for something like "known good customer" or "asked us to close their account".

Tags can be applied from the review queue as somebody decides, from a verification, from a person, and in bulk from the verifications list.

Keeping the list sane

Two things stop the vocabulary sprawling.

Names are matched after normalising them, so "High Risk" and "high-risk" are treated as the same tag and never become two. The editor tells you when a new name would clash with a tag you already have.

Renaming reaches every case already carrying the tag, including decisions you have already sent, so the console warns you before you do it.

Retiring stops a tag being offered on new cases. It stays on everything that already carries it, and it disappears from this list while remaining visible on those verifications. You can create the same name again later.

Who can do what

Reviewers and developers can apply tags and create new ones, because stopping the queue to ask an owner for a label is how teams end up with free-text notes instead. Renaming, recolouring and retiring is an owner's job, since a rename reaches history.

Read-only seats can see the tags on a row but not apply them. That is deliberate: a seat that could not resolve a tag would render coloured blanks beside rows it is allowed to read.