Triage and Workflow

Task IDs and project keys

Updated October 2nd, 202684 views

Every task has a number that is short enough to say out loud. BD-42 is how a task is referred to in a standup, a commit message, or a message to a reporter.

Numbers count per project

Task numbers start at 1 in each project and count up independently. Your project's first bug is 1 whether you created the project today or last year, and two projects can both have a task 42 without any relationship between them.

The project decides which task a number means. That is why every task URL carries the project slug: /projects/your-project/tasks/42.

The project key

Each project has a short key — 2 to 10 uppercase letters or digits, starting with a letter — that is shown in front of the number. A task in a project keyed BD reads as BD-42.

The key is derived from the project name when the project is created. Bug Dump becomes BD, Quality Control becomes QC, a single-word name like Kookee becomes KOOK. You can change it at any time.

To change a project key: open the project, go to Settings, edit the Key field, and save. The field uppercases what you type.

Keys are not required to be unique across projects. Two of your projects can both use APP; the slug in the URL is what separates them.

Where the key appears

The key is shown wherever the number is shown:

board cards and the task page
the side panel on the board
the public portal, in the task list and on each task
in-app notifications and report emails
Slack, Telegram, and email integration messages

Which URLs open a task

A task answers to two addresses, and both work in the board's side panel as well:

/projects/your-project/tasks/42        the form BugDump links with
/projects/your-project/tasks/BD-42     the form a person is likely to paste
/projects/your-project/board?peek=42
/projects/your-project/board?peek=BD-42

The prefix is not case sensitive, so bd-42 works too. Whichever address you open stays in the address bar — BugDump does not rewrite one form into the other. Every link the app generates, including Copy link in the task panel, uses the bare number.

Anything else is treated as a wrong address and shows the 404 page rather than opening a task:

a prefix that is not this project's key, such as QA-42 in a project keyed BD
a padded number, such as BD-007
a number no task in the project holds

Renaming a key

Renaming a key relabels every task in the project at once and renumbers nothing. BD-42 and NEW-42 are the same task, and its number never changed.

The one cost: links someone shared carrying the old prefix stop resolving, because a prefix that is not the project's current key is a wrong address. Links that use the bare number keep working, and that is the form BugDump puts in every link, email, and payload it generates. If you are about to rename a key that has been in circulation, that is the thing to weigh.

Numbers are never reused

Deleting a task does not free its number. If your newest task is BD-9 and you delete it, the next task created is BD-10.

This is deliberate. If numbers were reused, a link or a commit message referring to BD-9 would silently start pointing at a different bug.

Reporters attaching a report to a task

With allowTaskAttach enabled in the widget, a reporter can attach their report to an existing task by entering its number. Give them the number itself — 42 — rather than the full label.

Task IDs and the API

Numbers, not labels, are what the API works in:

Webhooks and integrations send publicId and taskPublicId as plain integers, plus a taskKey field carrying the display form such as BD-42.
The MCP server's get_task takes the integer behind the label. Pass 42 for BD-42. Its list_tasks and get_current_project tools report the project key, so an agent can render labels back to you.

A personal MCP token is bound to one project, so a number is unambiguous within its session. A sign-in connection reaches all of your projects, so the agent passes the project's slug as project alongside the number; list_projects returns each project's slug and key.