At Redmineflux, we build plugins and managed Redmine environments for development teams. Issue tracking sits at the center of that work, it is where ownership, status, priority, and progress live.
Redmine is flexible by design. That flexibility is useful, but it also means a new instance can feel under-defined until the issue tracking model is properly configured.
This guide explains how to set up issue tracking in Redmine, which settings matter most, and where Redmineflux plugins add structure when core Redmine is no longer enough.
Before changing settings, it helps to understand what Redmine treats as an issue. In Redmine, an issue can represent a bug, feature, support request, internal task, test item, or almost any other work object tied to a project.
That flexibility comes from a few core building blocks:
Answer capsule: A good Redmine issue tracking setup combines trackers, statuses, workflows, permissions, and custom fields into one consistent model. The goal is not to create more settings. The goal is to make issue creation clearer, handoffs cleaner, and reporting more reliable across the whole project lifecycle.
If these pieces are not aligned, teams usually experience the same problems: vague tickets, inconsistent states, unclear ownership, and reporting that cannot be trusted.
One of the most common setup mistakes is trying to build the whole process around statuses first. In practice, trackers should come first because they define what kind of work the issue represents.
For example:
If all of those are forced into one generic issue type, the result is either too much friction or too little structure.
For many software and IT teams, a clean starting model looks like this:
This is usually enough to separate work meaningfully without creating a tracker list so large that no one uses it consistently.
If your team handles repetitive intake, the Issue Template Plugin is often the next useful layer because it standardizes issue creation for each tracker and reduces missing information at the source.
Statuses should reflect actual workflow states, not aspirational labels. The cleanest Redmine setups usually use a small set of states that map directly to real team behavior.
A practical example:
This works because each state signals a meaningful handoff or decision point. It also keeps reporting readable. If the system contains fifteen statuses with overlapping meanings, users stop trusting the board and managers stop trusting the reports.
Use statuses for workflow milestones, not for every nuance of work.
Good status questions:
Poor status questions:
Those cases are usually better handled through notes, tags, or custom fields rather than new statuses.
For agile teams, the Agile Board Plugin becomes useful here because it turns those statuses into a clearer visual flow for Kanban and Scrum execution.
This is where Redmine becomes much more powerful than a simple ticket list. Workflow rules let you decide which roles can move which trackers between which statuses.
That matters because a good workflow protects process quality without forcing everyone into the same permissions model.
Examples:
New to In ProgressResolved to QA or back to In ProgressThis is what makes Redmine suitable for mixed teams. You are not just tracking issues. You are controlling how work moves between people and functions.
Not every tracker needs a completely separate workflow. Use separate workflows when the work type genuinely changes the handoff logic. If the process is basically the same, reuse the same structure and keep administration lighter.
A good rule is this: separate workflows should reduce confusion, not create configuration overhead.
Once trackers and statuses are clear, custom fields become the next quality lever. This is where you capture the information your team repeatedly asks for during clarification.
Useful examples:
The best custom fields answer questions that otherwise appear in comments after the issue has already been created.
This improves three things at once:
If your team still closes work with missing steps, the Checklist Plugin is a strong companion because it helps enforce definition-of-done discipline at the issue level.
Teams often over-correct once they discover Redmine’s flexibility. They add too many required fields, too many statuses, and too many workflow branches. The result is a ticket form nobody wants to use.
The goal of Redmine issue tracking setup is not maximum configuration. It is minimum ambiguity.
A strong setup usually has these traits:
If your issue intake is repetitive and prone to omissions, templates usually work better than more admin rules. That is why the Issue Template Plugin can improve quality without making the issue form feel heavier.
Redmine reporting is only useful when the workflow underneath it is consistent. Once your tracker and status design is stable, you can filter and report by:
That gives project managers a usable operational view instead of a flat ticket dump.
If your team also needs time visibility, connect this setup to the existing How to Track Time in Redmine guide and the Timesheet Plugin so execution effort and issue flow stay in one system.
If capacity planning is becoming the next bottleneck, this setup pairs naturally with How to Manage Workload in Redmine and the Workload Plugin.
For leadership reporting, the Custom Dashboard Plugin adds a stronger visual analytics layer on top of issue and project data.
Core Redmine is very good at flexible issue tracking. It gives you:
For many teams, that is enough to start.
The gaps appear when teams want:
That is where Redmineflux plugins move Redmine from a capable tracker into a more complete operating system for delivery.
Useful next layers include:
If you want a simple starting point, this is a strong baseline:
This keeps the system light enough to adopt but structured enough to scale.
Common Questions About Redmine Issue Tracking
1. How do I set up issue tracking in Redmine?
Start by defining your trackers, then create a small set of meaningful statuses, configure workflow transitions by role, and add only the custom fields your team actually needs. A good setup makes issue creation easier and issue movement more consistent across the project lifecycle.
2. What is the difference between trackers and statuses in Redmine?
Trackers define what kind of work an issue represents, such as Bug or Feature. Statuses define where that issue is in its lifecycle, such as New, In Progress, or Closed. Trackers classify work. Statuses show workflow progress.
3. How many statuses should I use in Redmine?
Most teams should start with a small set of workflow states that map to real handoffs. Too many statuses make boards harder to read and reports less reliable. If a status does not represent a meaningful change in ownership or progress, it usually does not need to exist.
4. Can Redmine support different workflows for different issue types?
Yes. Redmine lets you configure workflows by tracker and by role. That means Bugs, Features, Support issues, and Tasks can each follow different transition rules while still living inside the same Redmine environment.
5. Which Redmine plugins improve issue tracking the most?
The most useful additions depend on the gap you are solving. The Agile Board Plugin improves visual workflow execution, the Issue Template Plugin improves intake quality, the Checklist Plugin improves completion discipline, and the Helpdesk Plugin extends Redmine for support-driven issue flow.
Redmine becomes much easier to manage once issue tracking is treated as a system instead of a list of tickets. Clear trackers, meaningful statuses, practical workflows, and a small number of useful custom fields create the foundation. That is the perspective behind the Redmineflux website as well: help teams get more out of Redmine first, then add the right plugin layer when they need stronger structure without forcing a tool migration.
Redmine becomes much easier to manage once issue tracking is treated as a system instead of a list of tickets.
Clear trackers, meaningful statuses, practical workflows, and a small number of useful custom fields create the foundation.
Build a Redmine setup your team can actually rely on
That is the perspective behind Redmineflux: help teams get more out of Redmine first, then add the right structure when they need it.
