Has this ever happened to you? You rename or remove a group in Jira. Jira handles the change in most places, but rules in workflow transitions need to be manually updated. My application has more than ten workflows and each has dozens of transitions to check. Here are some options to handle this situation:

• Open every workflow and open every transition to look for the group in condition. validator, and post function tabs. (That’s 4-5 clicks per transition!) This sounds like a horrible way to spend the weekend.
• Export each workflow individually and download it in XML format. Then search each XML file for the element’s name and ID. This is better than the first option, but still a very manual process.
• Search the “descriptor” field in the workflow database table. Of course this requires direct database access (which may be a security issue)and this access is not even a possibility in the Cloud deployment type.
• Use the REST API or an app like Salto Configuration Manager for Jira to find all the instances for me.

I’ll set up Salto to see how it helps manage configuration changes. 

‍

‍

Quick Set Up 

Salto is really fast to set up. Simply sign up for a free account on Salto’s website. Then connect the Salto app to your Jira Cloud or Data Center application. All you need is your application’s web address, an email address, and a token generated from your Atlassian user profile.

‍

‍

After connecting your application, all that’s left to do is to get (or “fetch”) your application’s configuration data. You can fetch during the  connection process (pictured) or manually fetch information later from the Salto application. For more set up information, see the detailed set up  instructions at: https://help.salto.io/en/articles/6982422-getting-started-with-salto-for-jira. 

‍

Salto Exploration 

I’ve just set up my Salto environment and completed my first Jira configuration fetch. Now what? I’ll use Salto’s “Explore” tab, to find specific Jira  settings and understand where they are used.

‍

My Test and Results 

Here’s one way to use Salto to uncover impacts to configuration changes. 

‍

Goal 

Understand the impact if I rename or delete the “Human Resources” global group in Jira. 

Previously, this research was a bit of a guessing game of “Who’s filters will break?” or “Which workflows will stop working?” or “What errors will  users immediately report?”. Thankfully, Salto provides the needed insight to make good configuration decisions. I’ll know exactly which Jira  elements to adjust or address before making a change. 

‍

Method 

Before making any changes, I need to find all the places the “Human Resources” group is used. This exploration helps me understand the impact  if the group is removed, changed, or simply needs a periodic usage audit. The group is probably used in permission and notification schemes, but  what about in other hard to find or hard coded areas like workflow conditions? Until Salto, there were very few ways to find this information. 

I’ll start my exploration with a keyword search. At the top of the left panel is the search feature. The search checks all areas of the configuration  regardless of how complex the schemes and associations are. In the screenshot, I’ve entered “Human Resources” in the search box to see what  Salto finds.

‍

‍

‍

In seconds, Salto found 10 matching results to explore. How long would this take to achieve manually? It would be many hours of opening  schemes, searching through settings, and likely missing some application areas along the way. With Salto my manual search days are over! Now  there's a great way to inspect, maintain, and understand Jira’s configuration settings. 

In the screenshot, there are six results in the “Elements” tab and four results in the “Content” tab. I’ll explore each tab to understand the findings. 

‍

Elements 

Use the “Elements” tab to browse Jira objects like boards, custom fields, issue types, roles, and much more. This tab contains each element’s  configuration including its properties and dependencies. My “Human Resources” search result includes a group, a Jira project name, and some  components in a Jira project. 

In the screenshot, I’ve clicked the “Human Resources” group in the left sidebar to see exactly where in the Jira project the group is referenced.  The right side of the screenshot shows that the “Human Resources” group is used in a security scheme and a workflow.

‍

‍

Next I’ll further examine the workflow information Salto provided. 

‍

Understanding the Search Result
‍

The search result contains a lot of helpful information. Not only did it find the specific workflow but also the specific transition and condition where  the group is embedded. Now I know exactly where to go in Jira to find this instance of the “Human Resources” group. 

The example search result contains: the name of the workflow, the exact transition where the group is embedded, the transition’s type (e.g.,  trigger, condition, validators, or post function), the specific condition, the condition’s configuration, and the condition's type. (e.g., group, project  role, only assignee, etc.) 

Tips:

• In Salto, and in many programming languages, the count of elements starts at zero. As an example, if there are three transitions, the first is  counted as “0”, the second is counted as “1”, and the third is counted as “2”. These count IDs are used when viewing result data in Salto’s. In  the example, “transitions.2” means the third workflow transition. 
• The first transition in every Jira workflow represents the issue’s “create” action. Don’t forget to include it in position “0” when counting result  elements. 

‍

‍

Content 

Next, I’ll explore the same search result in the “Content” tab. Salto scans every part of the configuration to find any term. It looks in user email  addresses, IDs, URLs, variables, embedded values, strings, project names, groups, code snippets, selection field options, JQL queries,  automation rules, and more. 

References are grouped by type. In the screenshot’s middle column, the search returned instances of “Human Resources” in a Jira filter, a group,  and a project. I’ve selected the filter to display its details in the right column. The information is presented in configuration file format.

‍

The configuration is written in Salto's NaCl language. NaCl is short for “Not Another Configuration Language“. It’s an easy to read language that  describes the application configuration. Don’t worry, you don’t need programming skills to leverage this information! Salto automatically highlights  the results so you don’t have to hunt though code. 

Next, I’ll look at what NaCl reveals about this filter.

‍

‍

This NaCl segment shows the filter's name on line two and the owner on line four. “Human Resources” is also referenced on line five. That’s a  project name in the filter’s JQL statement. Line six indicates the filter is shared with others and line ten shows the group. 

Line ten maps to the filter’s visibility permission in Jira. In the example all “Human Resources” group members can see the filter and its results.

‍

Next Steps 

Now that I understand the impact of removing the “Human Resources” group, here’s what I need to do in Jira. 

Visit the “Groups” admin page and make a list of all users in the “Human Resources” group. 

Remove the group from the project’s security scheme. 

This means I’ll need to restore permissions by adding former group members individually and/or by adding a different group. Remove the group from the transition condition in the “HR: Simple 3 Step” workflow. Skipping this step may result in user facing workflow  errors. 

Notify the owner of the “HR Top Priorities” filter to update its view permissions. Otherwise former group members won’t see the filter. Address any other instances of the “Human Resources” group detected by Salto. 

Yay! I was able to find all instances of “Human Resources” in my Jira application, understand the impacts of modifying those elements, and  safely made the needed configuration changes. 

‍

Activities to Try 

Now it’s your turn! Sign up for a free account on Salto’s website, connect your Jira application, and fetch the configuration data. Use the “Explore” tab to search for:

• Something unique in your application like a custom group, status, issue type, automation rule, script, or your name or user ID. User objects (filters, boards, dashboards, subscriptions, etc.) created by a former user. Bonus points for updating or removing the unneeded  objects! 
• Workflows with statuses that prevent issue updates. (Hint: The status property is named “jira.issue.editable“.)