How to run issue tracking in Plane: A practical walkthrough

A bug is one kind of issue. So is a customer request, a follow-up from a meeting, a task filed to unblock a teammate, a defect caught in staging. They come from different places and carry different details, but they land asking the same things: what is this, why does it matter, who owns it, what happens next, and when is it done.

Volume is rarely the problem. Continuity is. An issue starts with a clear reason attached, gets worked for two weeks, and closes with a note that says shipped. Down the road, when someone asks why it was built that way, the answer is nowhere to be found, though the record sits right there marked Done. The reasoning dissolved into a Slack thread, the triage decision was never noted, and the work that resolved it lives under a different title in a different project.

Good issue tracking keeps that thread intact, from the moment an issue is raised to the outcome that resolves it, and readable long after. This is how that works in Plane. For the wider lifecycle every kind of work moves through, from identification to closure, see the issue tracking workflow and its stages.

An issue should arrive already understood

Give issues an identity with Work Item Types

The fastest way to make an issue difficult to track is to give it an identity that doesn't fit the work. A bug logged without steps to reproduce or the environment it happened in has to be re-investigated before anyone can start. A customer request with no account attached is one nobody can accurately weigh. The information that makes an issue actionable is specific to the kind of work it is, and a generic record asks for none of it.

Configuring Work Item Types fixes that at the source. Each type carries its own properties, so the fields a record asks for are the ones that kind of work actually needs, and nothing it doesn't.

Mark the properties that matter as required and the context is part of the record at creation. Keep that list short. A Work Item Type with nine mandatory fields doesn't produce better records, only fewer of them. The shape a type gives an issue at the start is also what lets it be handled correctly later, when different kinds of work move in different ways.

Bring issues in from wherever it starts

An issue starts in multiple places. A customer request might begin in a call, a bug might surface in Sentry, and a discussion might happen in Slack. The problem isn't getting that work into a tracker. It's getting it in without stripping away the context that made it worth tracking in the first place.

Work reaches Plane through more than one door, and each keeps the source attached rather than flattening it into a title.

Deliberate steps for every issue

Triage what gets worked on in Intake

An incoming issue isn't work yet. It's something that needs a decision. Is it worth doing? Is it a duplicate? Is it something for later? That's what Intake gives you a place to do. Submissions sit outside the project's own workflow. From there, the queue owner can accept it into the project, decline it, or mark it as a duplicate.

Accepting an issue is where it becomes real work: it moves into the project, picks up an owner and a starting state, and enters the workflow for its type. From that point it's no longer a candidate in a queue. It's live work with a place to be.

Narrow the queue with Plane AI

Triage gets harder as the queue grows, and most of that difficulty is reading. Long submissions to understand, near-duplicates to catch before two people work the same thing twice. Plane AI condenses a long submission to its point and flags likely duplicates against the backlog with a confidence score, so the queue arrives already narrowed. The decision still lies with the human. Plane AI just makes it quicker.

Individual paths for each issue

Give issues their own Workflows

Once an issue is accepted, it has to move, and bugs and feature requests don't move the same way. A bug might go through investigation, a fix, and verification. A feature request might need evaluation, approval, and delivery. Put both through the same generic workflow and the states stop telling you where the work actually is.

Work Item Types give an issue its identity and Workflows give it a path. Plane lets you define workflows for specific types, so bugs can follow one path while feature requests follow another, each with states that match the work.

A workflow also governs which transitions are permitted and who can make them, and Plane blocks the moves it doesn't allow, so the guardrails hold without anyone policing them. For that machinery set up end to end on one work type, see how a bug's workflow, states, and pull-request automation fit together.

Configure Approvals for judgment, automate the rest

Not every move through a workflow should happen the same way. Some need a person to decide. Some are predictable enough that doing them by hand is just friction.

Approvals mark the moves that need judgment. A transition can be held until a designated approver accepts or rejects it, with a different destination for each outcome, so the decision is a real gate and the record shows who decided and which way. Automations handle the moves that need no judgment at all: assign an owner when a type is created, raise priority when a label is applied, run the housekeeping nobody should be doing by hand. Approvals are for decisions. Automations are for the predictable actions around them.

Close the issue without losing the context

Work moving through a workflow eventually reaches an end state, and how an issue closes matters as much as how it started. A resolved bug records what actually fixed it. A delivered request closes against the work that shipped it. Marking an issue Done captures the resolution on the record itself, so the outcome sits with the original context rather than in a separate note someone has to go find.

That closed issue keeps its links. The request stays connected to the implementation work that fulfilled it, the bug to the fix that resolved it. Anyone opening it later sees the whole arc: what was asked, what was decided, what was done, and how it ended.

Knowledge base from the learnings

Use Wiki to capture the runbook

An issue records what happened to one piece of work. That is not the same as what the team learned from it.

Some resolutions are worth keeping: a recurring bug, a decision about how something should be handled, or a fix people will ask about again. The issue holds the specifics; the Wiki holds the lesson, where it stays discoverable after the issue is closed. Highlight a sentence in a doc and turn it into a linked work item, and the knowledge and the work point back to each other.

Let Plane AI do it for you

The same knowledge base can be built with Plane AI. Give it a simple instruction and it can pull together the relevant discussion, activity, and linked work into a full draft, ready for review and edits. It can turn a resolved work item into a runbook update, a troubleshooting guide, or a note for the team, without someone having to reconstruct the issue and its history by hand.

An activity log tells you what happened to one piece of work. Organizational knowledge is what stays useful long after that work is over. A system that keeps only the first loses the second every time an issue closes.

Visibility into your issues

Use Views to check the status

Day to day, what you want from the tracker is a read on where things actually stand. Which issues are still being worked on, which are waiting for a decision, which are blocked, and which haven't moved in a while. A view lets you see that at a glance. Filter and group by state, type, priority, assignee, and more, then save the view so the same picture is there whenever you need it.

A few things Views can surface:

• Work that's been sitting in the same state too long
• Issues blocked or waiting on someone else
• Requests that are ready to move but haven't yet

Track progress with Dashboards

Views answer what needs attention now. A dashboard goes further and shows whether the shape of the work is changing: intake climbing month over month, acceptance outrunning what the team can deliver, a queue that stalls in the same place every time. A single issue can't tell you that. The trend can, and it's usually the thing that tells a lead what to change.

Build your issue-tracking workflow in Plane

An issue starts as an ask. In Plane, you can give it the right Work Item Type, bring it in from wherever it starts, triage it, move it through a workflow built for that kind of work, connect the work that resolves it, and keep the useful context around after it's done.

The result is a work item that carries its story from the first request to the final outcome, without the team having to stitch that story together across different tools.

Set up a Work Item Type, connect an Intake channel, and watch one issue move from a request to a resolution with its context intact the whole way.

Start tracking issues in Plane