Get Closure with MantisHub – Issue Lifecycle and Workflow.

The main goal of issue tracking is to capture issues and drive them all the way to closure. A ticket is reported, and our aim is to have it fixed or resolved and then closed off. Of course, each issue needs to progress through several stages before it reaches its final resting place. It’s important to clearly define your overall issue-tracking process and align it with the status an issue can be in at any particular point. This typically refers to your issue life cycle.

MantisHub defines seven statuses to reflect the state of your issues. The following outlines how these statuses are used in a traditional software development process, but you’ll see that much of this is transferable to any issue-tracking scenario.

• New – This is the landing status for new issues and indicates it’s waiting on some review or action.
• Feedback – This status indicates that the issue is awaiting feedback from the reporter. It is used when more information is needed.
• Acknowledged – This status is used by the development team to indicate agreement with a suggested feature request or support for what the reporter is suggesting.
• Confirmed – This status is typically used by the development team to reflect that they agree with what the reporter is suggesting in the issue and that they have confirmed and reproduced the issue.
• Assigned – This status is used to reflect that the issue has been assigned to one of the team members and that the team member is actively working on the issue.
• Resolved – This status is used to reflect that the issue has been resolved. For added information, an issue can be resolved with one of many resolutions. For example, an issue can be resolved as “fixed”, “duplicate” or “won’t fix”.
• Closed – This status reflects that the issue is completely closed and no further actions are required on it. It also typically hides the issue from the View Issues page. Some teams use “closed” to reflect sign-off by the reporter and others use it to reflect the fact that the fix has been released to customers.

Typically, issues move from New to Closed, but you may need to return to a previous status. For example, while an issue is assigned, it may need to be moved back to Feedback to get more information from the reporter. Or, after resolution, a ticket may need to be reopened. Some statuses may also be skipped altogether; smaller teams, for example, may not need to use the Acknowledged stage. Others may wish to skip Resolved and go straight to closing the issue.

When determining your specific workflow and how it aligns with MantisHub statuses, it’s important to note that each of these seven statuses maps to one of three definite stages in an issue’s life. This affects how MantisHub treats issues. For example:

• Any status-related filters use this (e.g. Hide Status field).
• Some workflow settings depend on these such as ‘when is an issue read-only’, and
• your resolution values need to make sense with the status value. Check out our KB article on valid combinations of status and resolution for details.

MantisHub determines this relationship by assigning a code to each of these statuses and using this to define the 3 stages.

1. Open – at this stage, your issue needs attention and is actively being worked on. It will appear in filters and reports as an open ticket. This stage covers statuses from New through Assigned, or code values 0 to 79.
2. Resolved – at this stage your issue has been addressed but there may be some follow up (e.g. release, documentation, notifications etc). This stage contains the ‘Resolved’ status or code values 80 to 89.
3. Closed – all work relating to this issue has been completed. This stage contains the closed status or code values 90 and above.

These stages and code values are particularly important if you’re considering customizing your status values.

Customizing your statuses

The seven default status values work really well for the vast majority of our customers. The terms are generic, intuitive, and flexible enough to apply to any environment. However, we do offer the option to customize them for qualifying plans. The simplest changes are hiding any defaults you don’t use or changing the name or color of existing defaults. Less straightforward, but also commonly used, is adding custom statuses.

When adding custom values here, there are 5 items of information you need to provide. While it’s tempting to just provide the new status name, you also need to define some peripheral terminology for the system such as what phrasing you want for email notifications. And it’s important to make sure to provide the requested terminology for any specific languages in which you use your system as these are not included in the system translations. All the details can be found in the KB article customizing issue statuses.

Workflow transitions

Another way to customize your workflow is by locking down transitions between each status. By default you can move freely from any status to another. But you may want to lock in certain behavior. For example, you may want the system to work such that once a new issue is changed to a higher status it can’t go back to being new. So you can disallow transition from any state back to ‘new’. Or perhaps you want to make sure all tickets go through the resolved state before being closed, so you would disallow all transitions to the closed state, except the transition from resolved state.

You can also lock down transitions according to a user’s access level. By default, developers and above can change an issue to any status; the only exception is that reporters can, of course, create issues in the New status. There is a simple checkbox configuration option to give reporters permission to reopen or close issues, and this is configurable in the workflow thresholds.

To give you an example of making use of workflow transitions, let's say you want all managers to sign off on issues before they are closed. You could set the minimum access level allowed to transition to closed status to manager. Check out the article on workflow transitions for more details.

Helpdesk workflow

When using MantisHub Helpdesk to handle incoming customer tickets submitted via email, MantisHub suggests a number of tips and shortcuts, as well as a specific workflow. In a customer support scenario, your issues or tickets will transition frequently between the feedback and assigned statuses. When responding to customers, you should set the status to feedback, indicating that you are waiting for a response from the customer. Once a customer replies, the ticket is automatically set to an assigned status, indicating that it’s waiting for your action. The workflow suggests a streamlined approach for handling these tickets and also takes into account which types of activity within the ticket will trigger notifications to your customers. Have a read of this article and many more on our Helpdesk feature for your customer support needs.

Addressing your workflow process and utilizing our intuitive issue life-cycle will definitely save your team time and money. Or consider tapping into the many ways you can tailor it to your needs. Improve efficiency and create simplicity in your issue tracking process and get closure :).