Redmine trackers, workflows and roles setup

A tracker is the issue type in Redmine, such as Bug, Feature or Support request. Each tracker carries its own set of statuses, so a Bug can be New, Triage, In progress and Resolved while a Feature follows a different path. The workflow then decides which status changes are allowed. Redmine stores a separate transition map for each combination of tracker and role, which means the same person can have different options depending on the issue type they are editing. Before writing any transitions, list the statuses each tracker really needs and remove the ones that no team uses. Every extra status multiplies the number of transitions an administrator must maintain.

Think of a workflow as a table of permissions. For each role and each current status, the table lists the statuses that role may move the issue to. Field permissions work alongside it. For each tracker, role and status, an administrator can mark a field as read-only, required or editable. These settings let you lock a resolution or a root cause field until an issue reaches a later stage, and they stop reporters from changing data that only engineers should set. Confirm the exact layout of the workflow and field permission screens in your Redmine version, because the labels and grouping have changed across releases.

Illustrative example: a bug tracker with the statuses New, Triage, In progress and Closed. Reporters may create issues and see them, but the transition from New to Triage is allowed only for the Developer role. Only the Project lead role may move an issue from Triage to In progress. The Severity field is required when an issue leaves Triage and read-only for everyone except the lead afterwards. In this design, a developer cannot start work without a lead's decision, and the lead can see the reason in the required field. Writing the rule down as a short sentence like this before you configure it is a useful check on whether the workflow is what the team actually does.

Roles alone do not decide what a user can do. A user with no role in a project cannot act there, regardless of how generous the workflow is. Membership and role permissions govern whether a user can view issues, add notes, edit or move issues in that project. A workflow only narrows what an already permitted role can do. If a user cannot change an issue, check the project membership and the role's permissions before you change the workflow. Also confirm which roles are assigned to each project, since a role that is valid in one project may be absent in another. Keep the number of roles small enough that each one maps to a real job, because every extra role is another row in the workflow table to review.

The maintenance cost of a Redmine workflow model grows faster than its visible size. Each tracker carries its own set of statuses and transitions, and each role that may act on an issue adds another dimension to the matrix. When a status is renamed, a role is split, or a tracker is added, the effect is not one edit. Every affected tracker and role combination has to be reviewed again, and the same check must be repeated after a Redmine upgrade or a plugin change. Before adding a tracker or role, ask the team to name the specific decision it supports and the people who will review it later.

Several practical limits keep the matrix readable. Share statuses across trackers wherever the meaning is the same, so that a status such as Resolved means one thing in every tracker that uses it. Keep the set of roles small and based on responsibilities that people actually hold, such as reporter, developer, reviewer and project manager, instead of one role per team or per request type. Where a field must be required or read-only at a given status, prefer one documented rule over a stack of exceptions. Each transition should have a short written rule stating who may perform it and why, so that a reviewer can tell whether a configuration matches the intent without reconstructing it from the admin screens.

Name one owner for the workflow configuration. This person is usually a Redmine administrator or a process lead who can approve changes to statuses, trackers and roles. The owner keeps the change log, decides whether a proposed exception is accepted, and confirms that the documented rules still match the configuration. Without a named owner, small local changes accumulate in production, and nobody can say which transitions are intentional. Agree on who may request a change and who approves it before the first change is made, and record the approver for each change.

Schedule a workflow review on a fixed cadence and record its outcome. A practical pattern is a short review each quarter and a full review before each Redmine upgrade or major plugin update. The review should compare the live configuration with the documented rules, list trackers and roles with no recent issues, and remove statuses or transitions that no longer serve a purpose. Record the date, the reviewer, the changes made and any exceptions accepted, with a link to the change request. Confirm the review cadence with your own change management policy and with the team that runs your Redmine instance, since the right interval depends on how often your processes change.

Test the configuration after every change, not only at go-live. Use a copy of the production database for trials where your data policy allows it, and run a small set of representative issues through each tracker and role combination. Check the transitions that are most often used, the required fields at each status, and the read-only fields that users depend on. Keep these test cases in the same document as the transition rules so they can be rerun quickly. A short, repeatable test set is what makes a simple model stay simple over time.

Workflow design fails most often because the inputs were assumed rather than written down. Before any tracker, status or role is changed, your team should hand over a current inventory of the issue types you use, the lifecycle each one follows today, and the people who hold each role. For every tracker, list the statuses an issue passes through, who moves it forward, what happens at each step, and where work currently stalls. Include the workarounds people use, such as statuses misused as flags or issues closed in a wiki page instead of Redmine. These are the cases a clean design must either absorb or deliberately retire.

Roles need the same precision. List each role that exists or is planned, the people or groups who hold it, and the projects where they apply. Record which actions each role must perform, such as creating issues, assigning them, closing them, editing estimates or viewing private notes. Approval and audit requirements belong here too. Name any step that needs a named approver, any field that must be locked after approval, and the retention period your auditors or internal policy expect for change history. If a control depends on an external standard or internal policy, ask the owner for the exact control wording rather than paraphrasing it.

Confirm the technical baseline in writing. Provide the Redmine version you run now and the database engine and version behind it. The current supported lines are 7.0.x, 6.1.x and 6.0.x, and the reader should confirm with their administrator which line they are on, because workflow changes made on an unsupported 5.1 or older release may need to be revisited during an upgrade. Also confirm the database, since Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, SQL Server 2012 or higher, and SQLite, which the installation guide does not recommend for multi-user production use. Note any plugins installed, because a plugin may add its own fields or statuses that the design has to account for.

Testing requires a non-production copy of Redmine with a recent export of the production database and attachments. Ask your team to confirm that the copy can be refreshed on request, that it holds realistic issue volumes without exposing personal data beyond what your policy allows, and that test accounts can be created for each role. Without this copy, workflow changes can only be checked by reasoning, and role permission problems usually appear only when a real user tries an action.

Sign-off should come from two people. The process owner for each tracker confirms that the statuses and transitions match how the work is done and that approvals sit with the right roles. The Redmine administrator confirms that the design can be built and maintained, that role permissions do not grant more access than the role description states, and that the change will survive the next upgrade. Record each decision in a short design log that states the decision, the reason, the people who approved it and the date. Keep this log with the configuration export so future reviews can see why a status exists or why a permission was granted.