Jira Housekeeping for Admins

This blog is for Jira administrators who lost a grip on the number of configurations in their instance. A clean instance is a joy to maintain and reduces the time, resources, effort and error to operate.

How could a simple setup with a couple of projects, some custom fields and adjusted workflows ended up in a jungle of schemes? Evolving instances with years of data and every team wanting their own customised configuration, run the risk of getting cluttered easily.

Also, things can get messy when migrating or consolidating data across sites, trying to untangle the history that has been built up.

Now, how to get back it back under control?

So this blog is about keeping everything in check. It’s written with a focus on Cloud, but of course also still applicable for Server and or Data Center (DC)

What are the best practices? And how to prune your existing instance into a lean and mean configuration!

Having learned from past experiences, we compiled a list of tips and tricks that we would like to share with our administrators.

Important: How to prevent clutter in the first place

First Step

How to prevent ending up in this situation in the first place? How to prevent an endless number of issue type screen schemes, workflows screens etc. when creating new projects?

Checklist when creating a project

An important time to think of re-use is when creating a new project. Jira allows two flavours of setting up projects: Company- and Team managed. Jira will prompt you to select an existing configuration.

With Team managed projects, the project lead is free to manage the project, including the creation of status and workflows. This is not the best practice from an administration point of view. As a result, we rarely recommended, or make use of it.

For those who are interested: Atlassian has created a page explaining all the differences between the two types of projects: https://support.atlassian.com/jira-software-cloud/docs/what-are-team-managed-and-company-managed-projects/

Consider the following items:

• Does the new customization justify the extra maintenance?
  • Ideally, the change/customization should support 80% of the organisation.
• Re-use configurations as much as possible
  • Especially when setting up a new project

Company managed projects allow for re-use of configuration.

• Allows for re-use of existing configurations
• Reduces maintenance / human errors
• Customizations can always be added afterwards

2nd Step: Cleaning up an existing instance

In case things got out of control, we compiled a list of actions that can be done. Just run the actions step by step in chronological order.

Tip: Use naming conventions!

Think of naming conventions for your CI’s. Like <Project>_<Description>_<version> or <function>. This makes it easy to identify the use of CI’s for fellow administrators but also to identify the use after many years of use.

Issue Types

Issue Type Schemes can typically be consolidated in a single scheme that covers multiple projects with identical issue types.

WARNING Jira allows deleting Issue Type Schemes that are in use. Ensure they are not in use by any project before deleting them.

Issue Types can usually be deleted if they are not used in any schemes. Jira will indicate if any issues use the specified issue type.

Workflows

Inactive workflow schemes items can be safely deleted.

Inactive workflows can be safely deleted. Scroll down to the bottom of the screen and open the “inactive” folder.

Workflows with identical status’? Consolidate them into a single workflow so re-use can be applied.

Screen

Screen schemes not used in any projects can be safely deleted.

Screens without Screen Schemes or Workflows can be safely deleted.

(Custom) Fields

Custom fields without screens and contexts can be moved to the trash can (Cloud). The data is then kept for 60 days before it is permanently deleted. In Server/DC there is no such option and the data is permanently deleted.

Lot’s of custom fields attached to issues, but not to a screen, can have an impact on performance.

WARNING Custom fields can contain many items for each issue plus its historical data. Restoring the custom field to a screen will also restore its view and history.

Field configuration schemes without any projects can be safely deleted.

Note: there is always the “Default Field Configuration” that can be used by projects. Depending on the configuration the screen can show up empty.

Status

Status’ without associated workflows can be safely deleted.

Optionally reorder the relevant items to the top of the screen. Or sort the status category in the right order.

Another suggestion is to go through the list of status names and check all statuses are still unambiguous. Otherwise, consider consolidating them into single items.

For Team managed projects: Project Leads can create their own status’ but they are unique for that specific project.

Note: this can have an impact on the Control Chart reports.

Resolutions

Perform a query to check if resolutions are in use. Perform or consider a bulk change to change resolutions before cleaning them up.

WARNING Check workflows for use of these resolutions

Priorities

Jira allows deleting issue Priorities that are in use but will give you the option to bulk change into an alternative priority.

WARNING Jira allows deleting issue Priorities that are in use.

Notification Schemes

It helps to consolidate notification schemes.

WARNING Jira allows deleting Notification issues that are in use.

Permissions Schemes

Permission schemes without attached projected can be safely deleted.

User Cleanup

Disable any users that haven’t logged in for, for example, 90 days to reduce the number of licenses. Atlassian allows to export user data with “Last seen in <app>” in .CSV format to quickly identify inactive users from large directories.

Note that this may not work with all configurations, especially if the instance is configured against a (read-only) external user directory.

Projects

Delete empty/obsolete and or archive (only available with Premium or Data Center) projects when possible.

Deleting (empty) projects frees up all of the Configuration Items (CI). If this is not available there is also the possibility to migrate it to an ‘archive’ instance to offload the production site. Don’t forget to delete the related Project Boards as they still remain after their project is deleted.

For server admins: Another way to ‘archive’ projects is to apply an ‘archive’ permission scheme – which you have to configure yourself – to make the project read-only or browsable for specific users.

Dashboards, Boards and Filters

After deleting projects, don’t forget to delete the related Project Boards, Dashboards and filters. Even though a project is deleted, it’s related boards, filters and dashboard remain active.

Cleanup Automation

A lot of the items above can be fully automated by using a tool like “Bob Swift CLI for Jira”. Note that TMC ALM has the knowledge to automate most of the actions as described above.

Contact TMC

If you still have any questions on this – or any other – Atlassian topic? The certified Jira experts of TMC ALM are happy to help you with all your questions, requests or remarks. Feel free to reach out to us via our contact page to start a conversation.