How can I have multiple releases at an epic level and only the active release at a story level?

[Rita Arellano]

Hi everyone, 

I would like to keep more than one fix version (release) at an epic level and only one fix version (release) at a story level. So, by default Jira can take more than one release on the fix version filed for the epic - and this works for us....

However, I would like to copy the fix version from the epic down to the story. The fix version I want to copy is the one that has the closes release date to today's date. Please see my logic below, its not working as it copies both releases from the epic to the story. 

This is my smart value for the variable I created, since the snipet below does not show the entire thing:  {{issue.fixVersions.filter(version => version.released == false && version.releaseDate > now()).sortBy('releaseDate').first.name}}

[Bill Sheboy · Accepted solution]

Hi @Rita Arellano 

Where did you find the syntax for that expression as there are several unsupported / incorrect things listed?  As written, that cannot work.  If your source was a bot / AI tool, I recommend no longer using it to answer automation syntax questions.

{{issue.fixVersions.filter(version => version.released == false && version.releaseDate > now()).sortBy('releaseDate').first.name}}

For conditional expressions, this is the syntax: https://confluence.atlassian.com/automation/jira-smart-values-conditional-logic-1081351607.html

And there are no filter() or sortBy() functions in smart values currently for lists: https://confluence.atlassian.com/automation/jira-smart-values-lists-993924868.html

Back to your original question, what you describe likely cannot be done with a Jira Data Center automation rule using list filtering.  (It might be possible with a Jira Cloud one using Lookup Tables.)

The reason it cannot be done with Data Center is because the rule would need to do this:

• for each version in the issue's Fix Versions field
• calculate the days-difference between {{now}} and the version's releaseDate
• find the minimum value for the days-difference
• and then select that version

This would require multiple created variables and list iteration, but variables cannot be "seen" inside of an iterator.

One possible workaround is to use the REST API endpoint with the Send Web Request action.  This endpoint could:

• filter by the status of of unreleased
• filter by the versions in the Epic issue
• order by the release date

Then the first one could be selected from the web response to set the Story's fix version.

Kind regards,
Bill

[Rita Arellano]

@Bill Sheboy I used a bot created by one of my coworkers. Anyhow, thanks, will try the REST API. By chance would JSON work here? I was able to use JSON, but it only gets the release date and not the release name: 

{

"fields": { "fixVersions":

[

{ "name": "{{issue.fixVersions.first.releaseDate}}" }

]

}

}

[Bill Sheboy]

Using first with {{issue.fixVersions.first.releaseDate}} refers to an unknown ordering of the values in the field as it is undocumented. 

It might be the order the versions were added to the field, but if values have been added / removed over time, there is no guarantee of what it is.  I recall there is a known, open defect for this unpredictability.  It is not necessarily the earliest release date.

Once the correct version is identified, the name attribute may be used: https://confluence.atlassian.com/automation/jira-smart-values-issues-993924860.html#Jirasmartvaluesissues-issue.fixVersionsissue.fixVersions

[Rita Arellano]

@Bill Sheboy 

I noticed an interesting behavior in Jira with the epic's fix version field.... So, I am able to add multiple releases on the fix version's field - which we already know we can dot that.... 

However, what I noticed is that when adding multiple releases in the 'fix Versions' field Jira can somehow organize the entered releases by order of which goes first - how it does that I am not sure.... 

I entered the below in the following order on the fix Version/s field: 
2025 December, 2025 November, 2025 October
and then I hit the checkmark - to save the issues... and I stayed and watched... and it saved the releases in the order in which comes first by date.... and I got this:
2025 October, 2025 November, 2025 December

Then I did the JSON thing: 

{
"fields": {
"fixVersions": [
{
"name": "{{issue.fixVersions.first.name}}"
}
]
}
}

It then - per my automation - it copied the first release on the epic which is '2025 October' 

It seems this should work, but again, agreeing with what you had mentioned - its unpredictable - what it considers first - we don't know exactly.... 

but after seeing how the epic rearranges the fix versions. I am thinking this is something we can possibly use. Thoughts? Please advise. 

[Bill Sheboy]

Short answer: I would not rely upon the order in the field to match your scenario needs.

When entering all the values at once as you did, perhaps it is ordering them in the field.  But it is likely in their "internal ID order", the "release order", or just the order you added them.  And if values are added later, I doubt it is re-ordering existing values when new ones are added.  (For example, if an earlier release was added to the end of the list.)

I just did a quick test with Jira Cloud, and the ordering was what I entered them in, regardless of the name, release date, etc.  And "first" was the first one I entered in my test automation rule.

[Rita Arellano]

@Bill Sheboy I am just gonna have to do a whole new automation, since now I have new reequipments added to this scenario.  Thanks so much for your guidance. You helped me identify what I can and cannot do. 

[Rita Arellano]

@Bill Sheboy 

I hope I'm not over-explaining this or going in circles, but I thought this might be helpful in our scenario. What are your thoughts? 

I believe I've clarified how the 'fixVersions' field organizes the releases entered into it. Based on my testing, I observed that when 'fixVersions' are added to the epic field and saved (by clicking the checkmark), the system appears to reorder the entries. The order reflects the sequence in which they were entered, starting from the bottom and moving upward - from what is on the Releases page. 

So, it reorganizes the order as it was created in the releases page. One can easily reorganize this order by a simple drag and drop - moving the releases around, and they will appear in this order under the epic's 'fixVersion' field. This will show '2025 August' show first then '2025 October' under the 'FixVersion' field. 

Also, the 'fixVersions' is an array field and we can use the below to get a particular placement of a 'fixVersions' 

I have used: {{issue.epic.fixVersions.get(1).name}} and it returns the 2nd release in the array (fixVersions) as it is index to start at 0. 
https://confluence.atlassian.com/automation/jira-smart-values-lists-993924868.html

If we need to add a new release, we could, but ensure its in the proper order under the Releases page, by drag and dropping the release in the order in which it belongs... 

[Bill Sheboy]

I am using Jira Cloud, and wonder if you try this what you will observe:

1. identify an issue which has never had a Fix Versions value
2. enter the value for "2025 October", and save your changes by leaving the field
3. enter the value for "2025 August", and save your changes by leaving the field

What is the order of the versions in the field?

I hypothesize it matches the order of entry (i.e., October and then August) and not the order on the Releases Page.

[Rita Arellano]

@Bill Sheboy Ok, I just created an issue and updated it. Here are my findings:

1. Created new issue and put in '2025 October' on the 'fixVersions' field. 

I then waited a min after saving the 1st entry....

2. I went back and added '2025 August' on the 'fixVersions' field. 
After saving, it reorganized them according to the order entered from the releases page. 


I tried this over and over again - crating a new issue (epic) and adding the releases in the fixVersions field one by one - and it still placed them in the "appropriate" order.... 

[Bill Sheboy]

Looks like the behavior is different for Data Center and so you may rely upon the technique you found.

[Sahir Maharaj]

Hello @Rita Arellano,

Based on my understanding, copying only the nearest release from an epic to a story involves leveraging Jira Automation with smart values.

The smart value you’re using looks correct, but it might require further refinement in your automation rule configuration.

If you’re unable to resolve this, I suggest opening a support ticket with Atlassian for assistance in configuring the automation rule properly at https://support.atlassian.com/contact/#/.

[Bill Sheboy]

Hi @Sahir Maharaj 

You posted this:

Based on my understanding, copying only the nearest release from an epic to a story involves leveraging Jira Automation with smart values.

The smart value you’re using looks correct, but it might require further refinement in your automation rule configuration.

Please explain why you believe that smart value expression is correct and the source of your information.  Thank you.

Kind regards,
Bill