Issue with Automation Rule for Creating Release Version in Jira

[Sundram Trivedi]

Problem Statement: I have created an automation rule that triggers when a sprint is closed. It automatically releases and creates a new version. I also plan to extend this rule to add release notes on Confluence. However, I am facing an issue with generating the correct version name.

Current Setup: My sprint closes every second Friday. When the sprint is closed, the rule should create a new release version. The version name format should follow this pattern: Current version: TWX202503.1 Next version: TWX202505.1 Following versions: TWX202507.1, TWX202509.1, … TWX202601.1, etc.

Issue: The version name is not being generated as expected. I suspect there may be an issue with the automation rule logic.

Request for Help: Cross-check my rule – If there are any changes needed, please suggest modifications. Correct version name logic – How can I ensure that the version name follows the expected pattern? Any guidance or example automation rule adjustments would be highly appreciated. Thanks in advance!

[Bill Sheboy · Accepted solution]

Hi @Sundram Trivedi 

What do you observe happening that is not working as expected?  Please post an image of the audit log details for the rule execution (will all of the area at the right side of the log expanded).

Until we see that...

For scenarios like this, I recommend posting the complete expression used to form the new version name.  That will make it easier for the community to offer suggestions.

And, I recommend breaking up the creation of the version name into steps, perhaps storing the values with Create Variable, and writing them to the audit log.  That will help you progressively confirm / adjust the logic to create the new version name.

Kind regards,
Bill

[Sundram Trivedi]

Hi @Bill Sheboy ,

In the audit log, it shows "Version already exists," which is the same version that was recently released.

Variable name: TWX{{now.format("yyyyMM")}}.{{#=}}{{latestVersion.name.split(".").1}} + 1{{/}}

I tried implementing the Create Variable approach by first storing the version name in a variable and then using it to create the version. However, I am still facing the same issue—the version is not being created as expected, and I am getting a different version name.

in this variable name is : TWX{{now.format("YYYY")}}{{#=}}{{lookupVersions.name.sort.reverse.first.substring(7,9)}} + 2{{/}}.1

Smart value: TWX{{now.format("YYYY")}}{{#=}}{{lookupVersions.name.sort.reverse.first.substring(7,9)}} + 2{{/}}.1

[Bill Sheboy]

There is no smart value named {{latestVersion}}.  What are you expecting that value to contain?

What value is set to the Fix Versions field in the Edit Issue action?

And most importantly...your rule trigger is Sprint Completed.  Why not use {{sprint.id}} with the branch JQL to find the issues in the sprint?  The Lookup Issues action does not appear to be needed...and could return the incorrect issues than you expect: it will return ALL of the issues in completed sprints (or at least the first 100 of them).

[Bill Sheboy]

The list functions you show do not exist: sort and reverse.  When one wants to order the results of the Lookup Issues action, an ORDER BY clause is added to the JQL. 

But that will not help for this scenario because it cannot sort a list-of-lists (i.e., Fix Versions is a list within the lookup issues result, which is also a list)

There is no smart value named {{lookupVersions}}

Let's reset a bit: please describe which version you are trying to create.  That is:

• Are the issues in the sprint which just completed in one-and-only-one Fix Version?  Is that always the case?
• You describe two different ways to increment the version number: +1 or +2.  What is a list of example versions for your pattern?

[Sundram Trivedi]

I want to create an automation rule that releases the current version and then creates a new release version when the sprint is closed. I also plan to extend this rule to add the release notes to a Confluence page.

In each sprint, there is only one Fix Version available.

The version number should follow a structured pattern.

I will share a picture of previous release versions to clarify the expected naming sequence.

The version name format should follow this pattern: Current version: TWX202503.1 Next version: TWX202505.1 Following versions: TWX202507.1, TWX202509.1, … TWX202601.1, etc.

[Bill Sheboy]

Thanks for that additional information.  Please answer these questions:

How is the Fix Version field changing for the work item in the Sprint when the rule runs?

What should the rule do if there are multiple different versions assigned to the Sprint's work items, perhaps due to an entry error?

With what you have described thus far, your scenario seems to be this:

GIVEN a Sprint is in progress
AND the work items in the Sprint are assigned to one-and-only-one Fix Version
WHEN the Sprint completes
THEN release that one-and-only-one Fix Version
AND create a new version based on the naming convention, where...
    GIVEN the Fix Version's name indicates it is in the same year as {{now}}
    THEN create a new version by incrementing the numeric part of the version name by 2
    ELSE GIVEN the Fix Version's name indicates it is in the previous year as {{now}}
            THEN create a new version with the current year
            AND reset the numeric part of the version name to 1

Thus your version calculation needs conditional logic to check the current year relative to the version name to set the numeric counter.  I recommend using an if / else block and created variables to help with testing the rule, and once that works as expected, consider merging the conditions into a single logical expression.

[Sundram Trivedi]

Thanks for your response! The Fix Version is assigned only to issues in the Review and Done states. When the Sprint closes, only these issues are moved to the current release version.

Since only one version is assigned per Sprint in my project, there’s no concern about handling multiple versions due to entry errors. That simplifies the process.

For now, we can skip the Fix Version assignment since I’ll handle it later.

The main focus remains on ensuring the correct version naming convention when creating the next version refine the logic to generate the proper sequence based on the Sprint completion schedule.

[Bill Sheboy]

I recommend splitting this into four parts:

1. extract the year and counter from the version name in one of the issues
2. decide using conditional logic which year and number to use (as described earlier)
3. assemble the pieces together
4. create the version

Based on the initial rule you showed, you should have all of the pieces to build this.  I recommend writing the results of each step to the audit log to confirm it works as you test it.

[Sundram Trivedi]

I tried to implement the rule, but I'm facing issues with creating the version name unable to create correct variable. I am sharing the implemented rule and audit log. Please help me resolve this.

after lookup issue

create variable: latestVersionName

              value: {{lookupIssues.fixVersions.name.first}}

create variable: currentYear
               value: {{latestVersionName.substring(3,7)}}

create variable: currentNumber

              value: {{latestVersionName.substring(7,9)}}

create variable: nextNumber

              value: {{#=}}{{currentNumber.asNumber}} + 2{{/}}

create variable: nextYear

              value: {{#if(nextNumber > 11)}}{{#=}}{{currentYear.asNumber}} + 1{{/}}{{/}}                                    {{#if(not(nextNumber > 11))}}{{currentYear}}{{/}}

create variable: adjustedNextNumber

              value: {{#if(nextNumber > 11)}}01{{/}} {{#if(not(nextNumber > 11))}}                                              {{nextNumber.padLeft(2, "0")}}{{/}}

create variable: nextVersion

              value: TWX{{nextYear}}{{adjustedNextNumber}}.1

log action: Latest Version Found: {{latestVersionName}} Next Version Calculated: {{nextVersion}}

lookup issue: project = "TWX" AND fixVersion = "{{nextVersion}}"

release version: {{latestVersionName}}

create version: {{nextVersion}}

log action: Successfully Released Version: {{latestVersion}} Created New Version: {{nextVersion}} 

audit log:

Sprint completed03/30/2025, 00:54:04
Lookup issues03/30/2025, 00:54:04
Expand
Create variable03/30/2025, 00:54:04
Log action03/30/2025, 00:54:04
Collapse
Log
Latest Version Found:
Create variable03/30/2025, 00:54:05
Create variable03/30/2025, 00:54:05
Create variable03/30/2025, 00:54:05
Create variable03/30/2025, 00:54:05
Create variable03/30/2025, 00:54:05
Create variable03/30/2025, 00:54:05
Log action03/30/2025, 00:54:05
Collapse
Log
Latest Version Found: Next Version Calculated: TWX .1
Lookup issues03/30/2025, 00:54:05
Collapse
Unable to run the search while custom values were being defined: .
Custom Smart Value JQL Search: "(project = "TWX" AND fixVersion = "TWX .1") AND (project in (10107))" - The value 'TWX .1' does not exist for the field 'fixVersion'.
Release version03/30/2025, 00:54:05
Expand
Create version03/30/2025, 00:54:06
Expand
Log action03/30/2025, 00:54:06
Collapse
Log
Successfully Released Version: Created New Version: TWX .1

[Bill Sheboy]

Thank you for the additional details as they help identify where the problems exist.  Here are some suggestions:

• The variable named latestVersionName should use this value for the first Fix Version in the first issue found from the lookup.  Note this is a list-of-lists and so both first functions are needed.

{{lookupIssues.first.fixVersions.first.name}}

• In several places, the writes to the audit log do not match the created variable names, and so they write as empty.  For example, change {{latestVersion}} to {{latestVersionName}}
• Your conditional logic does not use the correct syntax: it cannot be mixed with the math expression conditions.  You could use the longer form of the if() function to help as that has true and false return values.  Note this format of the if() function does not include the pound sign # prefix as it is not using section handling.

Let's try these replacements for some of your variables:

• action: create variable
  • name: nextNumber
  • value: {{currentNumber.asNumber.plus(2)}}
• action: create variable
  • name: nextYear
  • value: {{if(nextNumber.asNumber.gt(11), currentYear.asNumber.plus(1), currentYear)}}
• action: create variable
  • name: adjustedNextNumber
  • value: {{if(nextNumber.asNumber.gt(11), "01", nextNumber.leftPad(2, "0"))}}

[Sundram Trivedi]

"The automation is working fine, but I want to reset the increment number when the year changes. Otherwise, the increment should continue as usual without checking if it exceeds 11.

However, I noticed that the current year is being fetched from the Fix Version. How can I modify the implementation to correctly reset the increment at the start of a new year while ensuring the numbering follows the expected pattern?"

I tried to set nextNumber variable usinf this value: 

{{#if(now.format("YYYY").asNumber != latestVersionName.substring(3,7).asNumber)}} 01 {{else}} {{latestVersionName.substring(7,9).asNumber.plus(2).leftPad(2, "0")}} {{/}}

but its not working. I fetch the current year and try to compare with the fixversion name(year) then set value accordingly. But its not giving any value.

[Bill Sheboy]

Once again: you are mixing incompatible smart value expressions / functions for logic and math.  Please read the documentation links I provided.

And...there is no {{else}} expression.  The only format of the if() function which provides true and false values is this one below (the one without the pound sign #), and it is quite limited in what values it allows for "true" and "false" as they are text strings:

{{if(smartValue, "value if true", "value if false")}}

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/#if

As it appears I am not being effective at explaining what does and does not work, I recommend pausing and meeting with your Jira Site Admin to seek assistance.

[Sundram Trivedi]

Hi @Bill Sheboy ,

"Thank you! I have successfully set up the automation rule for releasing and creating versions. I really appreciate your support and understanding throughout the process!"

[Bill Sheboy]

Awesome; I am glad to learn it is working!  If the suggestions helped, please consider marking this question as "answered" to help others with a similar need find solutions faster.  Thanks!

[Sayed Bares _ServiceRocket_]

@Sundram Trivedi can you share with us the full expression for version name? what is the output when you run the automation? 

[Sundram Trivedi]

Hi @Sayed Bares _ServiceRocket_

This is the audit log:
In the audit log, it shows "Version already exists," which is the same version that was recently released.

Variable name: TWX{{now.format("yyyyMM")}}.{{#=}}{{latestVersion.name.split(".").1}} + 1{{/}}