5 Jira administration best practices you should know

When managing Jira Data Center instances, a series of factors must be considered and kept under control to guarantee a correct and sustainable software function over time. That's why we've compiled a list of Jira administration best practices, especially for the newbies, who'll find it valuable when working with Data Center instances.

Working with Jira could be an overwhelming task, especially if you're new to it and don't have any background about the do's and don'ts, not to mention the immensity of Jira's basic concepts. It's a software tool that allows you to do a lot and leaves carte blanche to use the method that best suits you and how your team works.

Achieve a successful implementation of Jira following these tips >>

One of the significant advantages of Jira is allowing it to achieve the same result in different ways. Our experiences as Atlassian consultants have taught us that, at least, these following tips should be a must for every Jira Data Center Administrator -at a functional level, without getting into the actual system administration.

5 Tips for Jira Administrators of Data Center instances

These Jira best practices will specifically help less experienced Jira Data Center administrators. Through this simple "guide," you'll learn how to identify, in broad terms, those situations where "Custom Fields" should be created, how to reuse items such as issue types, custom fields, and workflows, also how to standardize naming conventions of our items/schemas, and some general tips on archiving issues. Let's get into it:

1. Create custom fields wisely

As any Jira instance grows and extends to other areas, the need for new custom fields is often imperative. However, having too many custom fields can saturate our instance (and your human brain!). To establish a rational criterion in certain situations, we give you some parameters::

•    Create custom fields as long as system fields are not appropriate, try to make them as generic as possible so others can reuse them, don't create fields with a custom name like XYZ Options, and use a custom field called Options.
  
  
•    Contextualize custom fields, given the context, the same field might have a different configuration, e.g., a type of field "Select List" could contain some values for one project and totally different values for another. In addition, having context in our custom fields will improve Jira's performance.
  
  
•    Don't duplicate custom field names, this can cause problems when performing JQL searches or developing any type of script.
  
  
•     Audit custom fields, as of version 8.16.x, two columns have been added to the custom fields view:
  1. Last value update: displays the last date when the field was used.
  2. Issues: displays the volume of issues the field is using.

These last two options allow for identifying the unused fields and taking the necessary measures.
                              Here are the values of the last update and the number of Jira issues where a custom field is used.

2. Establish clear and practical naming conventions for items

In Jira, it's possible to have multiple schemes, screens, workflows, etc., and it's simple to create chaos within our instance because of them. That's why here's the thing, try to mitigate it by establishing a couple of naming rules.

First, you should ask yourself whether the object will be used in a single project or shared with others.

We recommend you start with the project key and describe the object type for the first option.

For instance, imagine a marketing project using the key MKT, where we'll have a workflow and a default screen layout for all types of "Issue" except for the "Task." We could use something like this:

For the second option, let's suppose we've two options to carry out our development projects; these configurations are shared with multiple projects using templates, as we'll see in point number three.

In this case, we'll not use the project key as the suffix for configuration options as each of these is used by multiple projects.

For these types of projects, we could add the suffix "DEV," then the type of project, and end it with the object's description.

For example, for the type scheme of "Issue," we could use:

With this solution, we'll see a clean and organized scheme when navigating through the options in the Jira administration since it's in alphabetical order.

Learn how we created an extensive catalog of options in Jira for a large banking company >>

3. Get the most out of project templates

Although Jira comes with a series of standard projects, these projects may not be adapted to our needs in many cases. To overcome this, we can generate our own "template" projects.

Atlassian products appreciate when sharing the different configuration options within a project (schemas, issue types, templates, etc.). In short, we can generate a set of different configurations to create different types of projects and thus meet the needs of our organization's other teams or processes.

To create a project based on a template, we must perform the following actions:

1. Select Projects > Create a project
   
   
   
2. At the bottom, we'll find the item: "Create with shared configuration."
   
   
   
3. Select the "Template" project.
   
   
   
4. Assign a name, key, and leader to the new project.
   
   
   
5. Press "Submit".

As in Jira, there are different ways to achieve the same goal; another way to keep your project catalog organized could be by using Atlassian's Marketplace apps. 

4. Archive Jira issues to keep your instance clean

Another helpful tip is about archiving "Issues." If we have a large volume of "Issues," and we need to keep them audited in the future, there's a handy Jira feature for these situations. But first, keep in mind the following:

What does it mean that an Issue is archived?

•    Archived issues will be removed from the index, which means overall performance will improve.
•    Archived issues are read-only and cannot be modified. Only users with specific permissions will be able to view them.
•    They will not appear in JQL searches or the customer portal (in case you're using Jira Service Management).
•    They can only be exported by Jira System Admins.

How to archive issues in Jira?

To archive an issue, simply go to the "Issue" you need to archive and press More > Archive.

If, on the other hand, you need to archive multiple issues without selecting them one by one, you can use the bulk changes. To do so, you should:

1. Go to Issues > Search for issues.
   
   
   
2. Choose the JQL query that best suits your search.
   
   
   
3. Click Tools > Bulk Change.
   
   
   
4. Select the Issues to be archived.
   
   
5. Select the "Archive Issues" option.
   
   
6. Follow the wizard and confirm the issues archiving.
   

Which Issues should be archived?

1. Those unused issues in reports. Since they aren't indexed, they will not appear in Jira gadgets.
2. Issues that aren't updated or have been closed for a certain period of time, e.g., more than two years.

5. The importance of the Resolution field

This section will discuss the importance of Jira's Resolution field. In many cases, it's mistakenly believed that an issue has been closed depending on its current state. When we have an issue in "Done" or "Close" status, it will be so, but internally, for Jira, an Issue has finished its life cycle when the Resolution field has a value.

Bad practices preach having an issue with a "Close" status has no value in the Resolution field. To check if this is happening in your workflows, perform a JQL search that will show all the "Issues" with this problem. For instance:

Status = Closed, and resolution is empty

To solve this problem, it's necessary to correct the workflow by adding a screen requesting the Resolution field when moving to the final state or including a Post-Function in the transition leading to the final state, e.g., "Update Issue Field."

Also consider, if an issue can be reopened, we'll have to clean the value of that field. For this, it's advisable to create a Post-Function in that transition. We can reuse the Post-Function: "Update Issue Field."

Choose the Resolution field and name it None:

Once done, we'll have our workflows ready, and we'll not have this problem in future issues, but... What happens to tickets that have already been created and are closed?

There are several options:

If we have the ScriptRunner app, it has a "Built-In Script" called "Bulk Fix Resolution" that will allow us to give a value to this field based on a JQL filter previously saved.

However, if we do not have this app, we can perform the following operation:

1. Locate the Workflow of the affected issues and modify them.
2. Click "Add Transition", the wizard to create the transition.
   1. From status: "Any status"
   2. To status: "Itself"
   3. Name: "FixResolution"

Now we'll have to add the Post-function ("Update Issue Field") to the transition we've created before, assigning a value to the "Resolution" field.

Additionally, we recommend adding a condition. This way, only administrators can execute this transition, and users won't be able to run this transition -to avoid mistakes.

Once the transition is created, we execute it. If we have multiple issues affected, we "Bulk change" them. To do this:

1. In the top menu, go to Issues > Search for issues.
   
   
2. We'll perform the appropriate JQL search: issuetype = task and Status = Closed and resolution is empty.
   
   
3. With the results on the screen, click on the upper right corner of the screen: Tools > Bulk Change.
   
   
4. We'll continue in the wizard. In the section asking to select the operation, we'll use "Transition Issues" and then select the transition we've just generated, which is "FixResolution".
   
   
5. When the process is finished, all our "Issues" will have value in the field "Resolution".

IMPORTANT: The resolution date is automatically updated in Jira's issues when you set a resolution, so the value will be the time when the fix is executed.

As you have seen, there are a lot of situations you have to face when working with Jira and facing uncertainty, it's best to have the best possible solution at hand. We hope you find these tips for Jira Data Center implementations useful.

If you are looking for more information about different ways to export Issues from Jira or more tips when implementing Jira or other blockers, don't hesitate to visit our blog; here, you'll find different solutions. For now, if you need more help, please get in touch with us by clicking the button below: