Navigating the Complexity of Jira Configuration as Your Organization Grows

[#1]

One of the most significant challenges for Jira administrators is the growing configuration complexity of the Jira instances over time.

As a Jira administrator, you play a critical role in managing the configuration changes that your users request on a day-to-day basis. These changes can include adding new projects, custom fields, screens, automation rules, changing permission access, and more. While performing these changes may seem like an easy task for an experienced Jira admin, understanding if those changes have a larger impact on your instance can be a tricky task. 

To ensure your Jira instance continues to function smoothly, you must consider the impact of any changes you make. You must evaluate how the new configuration will affect the overall performance, user experience, and functionality of your Jira instance. In some cases, even small changes can have significant effects on your Jira instance.

For example, changing the name of a custom field that is used in a filter can make the filter unusable until it is updated to use the new name of the custom field. This is because Jira filters rely on specific field names, so modifying a field name without updating the new value in the filter will disrupt the filter's functionality.

It's important to note that Jira doesn't alert administrators when a custom field is modified, making it even more critical to consider the potential impact of any configuration changes carefully.

Now, consider the number of filters in your Jira instance. Do you have 10, 100, or even 1000 filters? It's impractical and time-consuming to manually check each filter to see if the modified custom field appears and then fix it accordingly. Can you do it? The answer is clear: no.

 Modifying a custom field can also impact automation rules.

If you modify a custom field that is used in an automation rule, the rule may no longer work as expected or may generate an error. Automation rules rely on specific field configurations to trigger actions or perform actions on issues.

 Let's say you have an automation rule that triggers an email notification to a customer when the custom field "Customer success" is set to a specific value. If you modify the custom field to include a new option or remove an existing option, the automation rule wont longer work as expected, as the condition doesn't  match the new field value.

Cconsider the number of automation rules in your Jira instance. Do you have 10, 100, or even 1000 automation rules? Given the number of automation rules, a manual check may not be practical, and it can take up valuable time and resources.

Same as filters, you may have more and more automation rules over time, checking them all one by one is not realistic.

So, what's the recommended steps for Jira admin before and after performing configuration change? I share some points from my experience that may assist.

Plan the change:

Before making any configuration changes in Jira, it's essential to carefully identify the required changes and create a plan for implementing them. Consider the impact of the changes on Jira workflows, filters, automation rules, screens, and other Jira elements, as well as users. Additionally, take the time to explore your Jira instance and identify any dependencies related to the change you plan to make. For instance, if you're planning to remove a group in Jira, you must do a thorough exploration of your instance to find all the places where the group is used. This will help you anticipate any issues or conflicts that may arise and ensure a smooth implementation of the configuration changes.

You can explore your instance manually or use some third-party such as https://app.salto.io/signup that allows you to explore your instance elements and see their dependencies.

Another option is to use the REST API to explore your instance. Keep in mind that using the Jira REST API to search for dependencies can be a complex process, and it's important to have a good understanding of the API and the Jira data model.

 Document your changes.

Before making any configuration changes, document the current settings and the changes you plan to make. This will help you understand the impact of the changes and track any issues that arise. If you use Confluence, consider documenting the changes there and linking them to the Jira task. This approach will enable you to easily track the changes in the future and assist with debugging if any issues arise.

Test changes in a staging environment

 It's best to test any changes in a staging environment before implementing them in the production environment. This will help you identify any issues or conflicts before they affect users.

Monitor the system.

It's important to closely monitor the system after the configuration changes have been implemented in order to promptly address any unexpected issues or errors that may arise.

In conclusion, modifying custom fields or other elements in a Jira instance can have significant impacts on dependent elements like filters and automation rules. As a result, it is crucial for Jira administrators to have access to methods and tools that enable them to explore and understand the relationships between various elements within the Jira instance.

[Kalin U]

A very well thought summary of best practices. Thanks for the share and the product mention.

I'm interested in the next installment :)

[Yatish Madhav]

Thanks for this @Gal Fatal  - a nice article mentioning an issue or bump in the road many face I am sure if it. Yeah, there are many config changes that have numerous knock on effects that are small to implement but affect in numerous places like the example of custom fields.

One aspect of Jira I love is in some of the schemes where a Delete option is available only if it is not used in any other elements. Validation is a key part of the application developement process that we, Atlassian and so many am sure try to invest in.

This also ties in with a Jira Clean up guide (https://community.atlassian.com/t5/Jira-Cloud-Admins-articles/Jira-Software-Instance-Cleanup-Guide/ba-p/2136279) that I know I am as part of 'taking over' and continuing to maintain and manage Jira / Confluence / Bitbucket instances esp when it has had lots of administrators previously. I do find that the APIs has helped but if there is validation pre-processing like in your example of deleting a field, it should check all other relevant 'elements', it would improve the system exponentially.

If there is a next installment, looking forward to it.

[Vish Reddy {Revyz}]

Thanks for sharing @Gal Fatal