Transforming Data with Jira Automation (Case In Point: Setting Resolution)

[#1]

In recent years, the term "migration" in the context of Atlassian has commonly referred to the transition from Data Center (DC) to Cloud. However, many migrations into Jira involve entirely different scenarios.

As part of my series on Software Development Life Cycle (SDLC) in Atlassian, I have dedicated an article to the topic of migrating data into your Jira SDLC configuration. In this context, data migration refers to transferring data from one system to Jira, or moving data from an older Jira configuration to a new one.

These migrations typically consist of three key components:

1. Extract: This operation involves retrieving data from the old system or systems.
2. Transform: During this phase, we manipulate the data to fit its new context.
3. Load: The final step is to bring the transformed data into the new system in the specified format.

Among these three components, I find data transformation to be both challenging and enjoyable. It's never a cookie-cutter solution. It always requires a deep understanding of the data and a unique, tailored approach.

Transforming data is seldom a one-step operation. Typically, the entire transformation process consists of several small steps throughout the migration chain. We can do the data cleanup and housekeeping at the source location. Then, we can manipulate the intermediate files we extracted from the source system. For example, mapping old record types into Jira work item types. Lastly, there is always the option to perform additional transformations once the data is in Jira.

I appreciate the ability to transform large amounts of data in Jira, as it enables us to address errors that may have gone unnoticed earlier in the process. Instead of having to repeat the entire procedure from the beginning, we can make precise adjustments to the data. After all, even with the best preparation and practice, we often find that we overlooked some details that only become apparent after the actual data migration.

When performing data transformation in Jira, there are a few routes we could use:

1. Bulk Edit: This is a straightforward method, but it may not be suitable for all transformation needs. For instance, if the transformation involves copying data from one field to another, bulk edit cannot help us.
2. Workflow Transition: This method involves adding a loop transition (action) in the workflow. By utilizing post functions on that transition, you can modify issues and then use bulk operations or Jira automation to transition all affected work items at once. The most powerful transformations through workflow transitions often require an app. For example, if you have JMWE on your site, you can use it to change issue links. This approach requires temporary configuration changes on the workflow (as we assume data migration is only done once). Depending on the post functions available on your site and your knowledge, they may be easier to configure than Jira automation.
3. Jira Automation: You can transform data through Jira automation on an ad-hoc basis without needing to change the workflow or apply other configuration changes. It's highly reusable simply by adjusting the trigger conditions (or, like I have done in the example below, by using a generic trigger). However, some Jira Automation configurations may require technical expertise and a more intensive understanding of smart values. Fortunately, many transformations can be accomplished with relatively simple rules. Another significant advantage of Jira automation is that it doesn't necessitate an additional app. 

Please note that these options are limited by volume. For example, Jira allows bulk operations on up to 1,000 work items in one call. Be sure to consider these limitations when planning your work.

Case In Point: Using Jira Automation to Set Resolution

One transformation I often need to perform during migrations is setting the resolution for imported work items. The correct value for the resolution field usually interacts with the status field and other fields, so it frequently requires adjustment to align with the new configuration. Additionally, when importing data from different systems, the resolution field is typically not present in those systems. Furthermore, Bulk Operation in Jira cannot edit the resolution field, which makes Jira automation the primary method for handling this task.

So here is a specific example:

For the newly migrated issues, if the status of the work item is CLOSED, they will be assigned one of two resolutions: If 'Fix versions' is not empty, set Resolution to 'Done'. Otherwise, set Resolution to 'Declined'.

The trigger I used for this rule is "Comment Added." I chose this trigger because I only activate the automation rule during the operational window, ensuring it does not run during normal operations. I prefer this type of trigger as it makes testing the rule much easier. Additionally, using a bulk operation, I can add a meaningful comment to up to 1,000 issues, triggering the rule for all of them. While I could also add a comment with the automation rule, this method allows me to quickly adjust both the selection of issues and the content of the comment in an ad-hoc manner, without affecting the rule itself. Once I have addressed the necessary issues, I can disable the rule and keep it ready for future use.

[s_gridnevskii]

Hm, I was 100% sure that you can only change resolution while transition to another status. Never knew this can be done in Jira Automation.