Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Set new version to issue based on partial version name criteria

Sorry, the description of our current state and where I've got to is necessarily long...

We have multiple streams of delivery in our project. The small team delivers a number of distinct apps. 

We currently set up a generic version per app in advance, then give them a version number when it's time to release one of the apps. We also use a status called "Ready for Prod" to collect tasks that are ready to release, as the last step in the workflow before Done. 

At any given time we should have several "next versions" available (e.g. Calculator NextVer, Timesheet NextVer, DocFlow NextVer). As one becomes ready to release we replace NextVer with the version number (e.g. Timesheet 2.65.1927), then release the version in Jira.

We also use Components, and some of the components are a 1:1 match with the apps.

When we hit Release in Jira I have two automations run

  • Transition all tasks in that version to Done
  • Create a new empty NextVer version

What I'd like to do is have automation that sets the appropriate NextVer when the task transitions to "Ready for Prod" based on the Component field.

The automation step Create Version allows me to set the version number using regex - {{"[.-9]+$|v[.-9]+$","NextVer")}}

However, the only way I see to set a version for an issue is to use the Edit Issue step and that only allows me to select from existing released versions. While this seems to remember the name not the DB ID for the release, I'm wondering if there's a more fool-proof way.

Q: Is there a way to set a version in automation using criteria based on part of the target version's name (e.g. regex or wildcard). Any ideas?

1 answer

1 accepted

1 vote
Answer accepted

Hi @Dave F 

Yes, I believe that is possible.

When you edit an issue's fixVersion in a rule, you may type in a smart value expression, it will appear below the field, and then you can select it.

Now comes the harder part for your use case: what do you type in for that expression?

I can think of a couple of ways to solve this:


Kind regards,

I think I see what you're suggesting @Bill Sheboy. We do have a predictable next version name courtesy of the automations I mention; their names literally end with "NextVer" and do not have any version number. However the Edit Issue step in automations only allows me to select from existing released versions, not planned releases. Also, I can't guarantee someone won't edit the version name before it's released.

Setting the Entity level property with automation then calling it later still leaves me with a static value I have to assume will be there when the time comes. What I'm hoping to do is look for the version name where the first part of the version name is known, but the end may not be, which is why I was hoping regex might be an option. 

The webhook option looks promising though, however even though I can get the API URI to work in the browser, the automation's validate option fails with 405 error, and I'm not in a good position to investigate.

Hmmm...You noted this:

What I'd like to do is have automation that sets the appropriate NextVer when the task transitions to "Ready for Prod" based on the Component field.

That seems to indicate you have Component values to indicate the product areas, and so the releases to use.  For example, Calculator, Timesheet, DocFlow, etc.)  Let's assume there is one-and-only-one Component assigned to the issue.

What if within that rule you use a lookup issues action with JQL to find the previous version for that Component, extract the value, and then increment using your standard naming convention?

The JQL for the lookup issues action would be something like this to get the done issues for that component:

project = myProjectName AND Component = {{}} AND fixVersion IS NOT EMPTY AND statusCategory = Done ORDER BY fixVersion DESC

Lookup issues is limited to return 100 issues, but that should not matter for your need.  Now you can grab the last released fixVersion with {{}} to split out and increment your version number using the text functions.


I've tested the JQL in our sandpit env and get results, all with the same fix version. So the query works. Thanks for that one. I also modified it slightly so it could be used anywhere:

project = {{triggerissue.project.key}} AND Component = "{{}}" AND fixVersion IS NOT EMPTY AND statusCategory = Done ORDER BY fixVersion DESC


However {{}} and {{}} return nothing/null.... which turns out is the same error I make when wanting one of something that can be multiple, I drop the S off the field name.

{{}} does the trick.

And for anyone else wanting to do something similar, the smart value to remove version numbers (e.g. v1.23 or 1.23) off a release and create a new similar one with NextVer on the end is:


 Thanks for the advice @Bill Sheboy, I couldn't have got there without you

Like Bill Sheboy likes this

I am glad to learn that helped, and sorry on my typo on the smart value name.  I wish they were validated better prior to allowing save (or during entry):

On that note, watch for the capitalization of smart values, such as {{lookupIssues}}.  The spacing and capitalization are not consistent for all fields/functions and sometimes the documentation is wrong too.  When in doubt, you can try this how-to article to find the correct smart values for fields:

Have a good one!

Just for anyone else trying to do this or similar in future, the automation I've ended up with is below. We use Component to set the Fix version to a planned release without a number. We add the number once the build server provides it. 

  1. Trigger based on transition
  2. If Component is not empty
    1. Lookup with JQL:  project = {{triggerissue.project.key}} AND Component = "{{}}" AND fixVersion IS NOT EMPTY AND status = Done ORDER BY key DESC
  3. If all match
    {{lookupIssues.fixVersions.size}} > 1
    {{}} = 1
    1. Edit issue. Set Fix version to: 

The minor modifications from Bill's suggestion:

  • If Component not empty check, because the JQL will err if that field is empty
  • If all match, so we don't have empty or multiple of either Components or Fix version
  • Changes the JQL to only find released versions, not the current planned unreleased version (e.g. exclude "Calc app NextVer") assigned to WIP tasks
Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events