Customizing Issue Priorities and Types

Issue types and priorities used to be a fixed set — bug / feature and a low / medium / high / critical ladder, the same for every workspace. They are your workspace’s own rows now: add and rename types and priorities, reorder them, delete the ones you added and don’t use, and control what a type does and what a priority looks like to the person filing the report.

This article covers Settings → Issue Tracker → Types and Settings → Issue Tracker → Priorities, and the three things that actually happen as a result of editing them: the AI agent sessions a type offers, the order the Priority sort reads, and what a reporter sees when they file a report.

Before you start

• You need View issues (issues.view) to read these tabs and Manage issues (issues.manage) — or workspace ownership — to change anything on them. Without the manage permission the tabs render read-only.
• A workspace can have at most 10 priorities and 10 types. The Add priority / Add type button is disabled at the cap, and the route refuses past it.
• The values every workspace is seeded with — bug and feature, and low / medium / high / critical — can be renamed and recoloured but never deleted. Their delete button is disabled with the note “Every workspace starts with this type. It can be renamed, but not deleted.”

Types: what each field controls

Each row in Types has:

• Team label — The internal name your team sees — the list, the filter and every Issue. Max 40 characters.
• Reporter button — The button text a customer presses on the report form (for example “Something is broken”). Max 40 characters.
• The unlabelled line under it (placeholder “The line under it”) — The short explanatory line under that button on the report form. Max 120 characters.
• Key — The stored value. Proposed from the team label while you type it, then fixed for the life of the row — read-only once the type exists. Lower-case letters, digits and single hyphens, max 40 characters.
• Colour and icon — How the type renders as a chip and tile throughout the tracker. Eleven colours; ten icons.
• Emoji — Leads the title the tracker writes when the reporter doesn’t give one. One emoji, not a word.
• What this type is — The type’s kind — defect, idea or other, chosen as one of three sentences. Decides which AI agent sessions the Issue offers.

Kind is the field that matters most. It’s not cosmetic — it’s what decides which AI agent sessions get offered against an Issue of that type. In the editor the three choices read as sentences, not as the enum:

• “Something is broken” (defect) — the product does not do what it should. Offers Verify this and Fix this.
• “Something is wanted” (idea) — nothing is broken; someone is asking for something new. Offers Verify this and Build this.
• “Neither” (other) — a question, a request, or anything else you file. Offers Verify this only, and withholds every session that writes code. If you add a type like “Question” or “Onboarding request,” set it to Neither so nobody has to explain why a coding agent opened a pull request against a customer’s question.

There are four agent sessions in total, and this is all of them:

• Verify this — Reproduces the report and writes back what was actually found. Writes no code. — defect, idea and other — every kind
• Fix this — Fixes the bug on a branch and takes the pull request to green. — defect only
• Build this — Builds the requested feature and takes the pull request to green. — idea only
• Ship it — Takes the green pull request to production. — No kind at all. It appears only when the Issue has an open linked pull request, whatever its type.

Two consequences worth knowing:

• An Issue with no type offers all three type-driven sessions — Verify, Fix and Build. An absent type narrows nothing.
• Only one code-writing session (Fix or Build) can be live on an Issue at a time.

These session buttons live on the Issue’s detail page and are shown to Atender superadmins only; setting kind is how your workspace tells that panel what one of its own types means.

Renaming a type’s label doesn’t change its kind, and doesn’t change which sessions it offers — those follow kind, not the label or the underlying key. Changing a type’s kind writes nothing onto existing Issues either: the buttons are worked out live on every render, so an Issue filed last month follows its type’s kind as it stands today.

Reordering types sets the picker order, which is the order the reporter’s buttons are laid out in.

Priorities: the order IS the severity

A priority row is simpler than a type: Label (max 40), Key (fixed once created) and Colour. No icon, no emoji, no kind.

What priorities have that types don’t is that position matters twice. Where a priority sits in the list — least urgent first — is where it sits in the picker, and it’s the severity the Priority sort reads. The list view’s Sort control offers Newest first, Oldest first, Recently updated, Priority and Status; choosing Priority orders Issues by their priority’s position, most urgent first. The Priorities tab says the same thing in its own words: “this order is what ‘Sort by priority’ reads, so moving one changes where its Issues appear.”

Drag “Blocker” above “Critical” in Settings → Issue Tracker → Priorities and both change at once — there’s no separate severity setting to reconcile. Treat the list as a ladder, not a shelf: the position you drop a row into is the position it will sort at everywhere in the product that orders by priority, because the sort reads the row live rather than a rank compiled in somewhere else.

A new priority is added at the end of the list, which is the most urgent end. Drag it if that isn’t where you meant it.

Renaming never moves the underlying key

Every Issue stores its type and priority as a key, not a label — that’s true for the team’s priority, the reporter’s stated priority, and the type. The key is proposed from the label while you first type it and then frozen; the editor shows it read-only with the note “A key never changes. Automation rules and saved filter links store it — renaming this type changes the labels only.”

Renaming a row in Settings only changes the label. It does not:

• move any existing Issue to a different type or priority,
• change what an automation rule matches on — a rule’s issue.type and issue.priority conditions compare against the stored key,
• change what a filter link matches on — in the Issue Tracker the URL is the filter state, so a bookmarked or shared list link carries the key in its query string,
• change the value the API returns or accepts for that field.

An automation built against a type before you renamed it keeps working after the rename, because it’s built against the key underneath, not the label you’re looking at.

Deleting a value

You can only delete a value your workspace added. The seeded types and priorities are permanent — the delete button is disabled on them, and the route refuses with “…is one of the types every workspace starts with. You can rename or recolour it, but not delete it.” So plan on renaming the seeded rows into your vocabulary rather than deleting them.

For a value you did add, deleting doesn’t leave existing Issues pointing at nothing:

• Every Issue currently on the deleted value is reassigned to another value you choose as part of the delete. For a priority that covers both columns at once — the priority your team set and the one a reporter asked for. The confirmation dialog tells you how many Issues will move, and only asks you to pick a destination when there are any.
• If the deleted row was the workspace’s default type or default priority (Settings → Issue Tracker → General), the default is re-pointed to the value you chose, so new Issues don’t fall back to something nobody picked.
• Automation rules do not run for the move, and any rule that names the deleted key stops matching. Deleting a type also removes its button from the report form.

Nothing is left in an orphaned state where an Issue silently loses its type or priority — but the delete is not a no-op for your automations, so check any rule that names the value first.

What the reporter sees

The report form a customer fills out doesn’t show your team’s vocabulary — it shows a narrower, reporter-facing projection of it:

• The buttons on the report form are your types, but labelled with each type’s reporter button text, not its team label, and described with the line beneath it. A workspace that adds a third type gets a third button.
• Nothing about a type’s kind, its team label, or its row id reaches the reporter. Those are for your team’s tracker views only.
• The form asks “How urgent is it?” from the same priority list your team uses, showing each priority’s label. What the reporter picks is carried as the Issue’s customer priority — a separate column from the priority your team sets internally while triaging. It also seeds the team priority at create time, after which the two move independently.
• A customer never sees your team’s internal priority judgement on their own Issue. Their view renders the customer priority and nothing else, and the priority chip is absent entirely when that field is empty — an Issue the team raised itself, or one created through the API without a customer priority, shows no chip. (Your team can edit a customer priority afterwards during triage, so the chip can show a value the team last set.)

This means renaming a type’s team label (say, “Bug” → “Defect Report”) has zero effect on what a customer sees on the report form unless you also update that type’s reporter button text — the two are independent by design, so your team’s vocabulary and your customers’ vocabulary can drift on purpose.

Summary

• Types carry a team label (your team), a kind (which AI agent sessions it offers), a reporter button and hint (your customers), an icon, a colour, an emoji and a frozen key. Max 10 per workspace.
• Kind maps to exactly this: defect → Verify this + Fix this; idea → Verify this + Build this; other → Verify this only; no type at all → all three. Ship it is never offered from a type — only from an open linked pull request.
• Priorities carry one order, least urgent first, and that order is both the picker order and the severity the Priority sort reads. Max 10 per workspace.
• Deleting works only on values you added — the seeded ones can be renamed but never deleted. A delete reassigns affected Issues to a value you choose and re-points the workspace default if it named the deleted row; automation rules naming it stop matching.
• Renaming only ever changes what’s displayed. Automations, filter links and the API all key off the underlying value, which a rename never touches.