Working with Priority

Priority in any helpdesk/bug tracking system is usually a point of contention between those who raise the issue and the development team or product owner. One person’s view of urgent must fix within 5 minutes is another persons “that can wait until next week” viewpoint. The crux of the matter is purely down to opinion and perspective as to what a priority should actually be. For the one user, the issue might be the biggest annoyance in their daily routine, but for the dev team, it is one user amongst thousands and there may be bigger priorities fixing something for the massive rather than the individual. So how do you set a priority such that it is meaningful to the team, but doesn’t offend the reporter when you change it from “High” down to “Low” priority.

As with most things, there is no right answer, but I want to suggest a couple of ways you can use Countersoft Gemini to manage this process.

Options available

1. Don’t let the user set a priority when they create a ticket.
2. Don’t let the user update a priority once a ticket has been created.
3. Create a 2nd field for user priority (and how to triage the issues)

Don’t let the user set the priority

This is the simplest option. Having not been given the opportunity to set the priority, they won’t have the expectation to adjust the priority. In fact, do they even need to view the priority? Should this just be an internal concept? Therefore every user’s ticket is the same priority, as far as the user sees. Of course this does limit the users in giving their perception of how important an issue is – you may well find users work around this by creating tickets with ****URGENT**** in the title!

Don’t let the user edit the priority

The next level up would be to allow them to edit the priority but not let them make subsequent changes to the priority. This will prevent the update wars where the user sets it as high, the developer sets it as low, then the user edits again and sets it back to high, etc. This could get tedious and usually will just be ignored by the support/developer team. However, this does lead to a frustration for the user when they leave it as low priority, and then realise they should have set it as “high”. They cannot edit, and will then usually make noise to have the priority changed. Pros and cons, you will have to decide what works best.

The final option?

There is one final option, which I have not mentioned, and the rest of this post will be talking about how to configure this.

The idea is you create a 2nd priority field either as a new custom field, or you could perhaps utilise the Severity field and using the Taxonomy feature of Countersoft Gemini you could relabel this to User Impact or such. This way, the user will feel they have provided some information as to the impact of the issue, but leaves the priority for the development team. This can be shown, or not, to the user as required.

The unselected option

By default, Gemini does not have an unselected option for the priority. Some users have got around this by creating a “dummy priority” called “<Select>” or “none”. However, they have issues in making this the default selection, and there are two steps which should be done to ensure this is reliable.

Here we have a default priority list from a standard template. First, we should add the new unselected value.

The first step would be to make this unselected value, the first value in the list. As things stand this value would appear at the end of the list:

Not massively helpful! Use the drag handle on the left hand column to move the item to the top as shown below.

This makes it appear at the top of the list, but it won’t always make it the first selected item:

This is because Low priority is set as the project default. We need to amend this:

Click on the settings menu item:

A popup will appear, and you should click the Defaults tab. Also check you’re in the right project from the drop down on the right hand side. You must have the permissions Set Project Defaults to be able to perform this action. If you cannot see the settings menu, or the Defaults tab, it is most likely a permissions issue and you should talk to your Gemini Administrator. You can set the defaults per Issue Type, but usually it would apply to All types and this drop down would remain unchanged.

Scroll down and find the Priority field and set it to be the new Not Set value.

scroll down to the end of the form and click the save button:

Then you can close the form.

When you create the issue now (assuming priority is visible on create for you) you will see the newly created value, and it will be preselected in the list.

If the user does not have permission to set the priority field on create, this default value will be used instead.

So now you can prevent the user from seeing the field on create, but still have a value set. You can also triage these issues and priorities them as you, the support team, see fit. In a future post, we will look at preventing the ticket being updated unless there has been a priority set.