JIRA Automation

[mathew Pelchat]

Hello all,

We are trying to use a JIRA automation to assign a "Capability Start Date" to our capabilities based on the first fix version release date of it's linked features. We are utilizing an "implements" and "is implemented by" link type. We have tried several iterations of this automation and have been partially successful. We have gotten the automation to identify the features under the capabilities by the issue link but and to identify the min fix version date using the smart value {{lookupissues.fixVersions.startDate.min}} but cannot get the automation to then pull and assign the date to the capability. I'm not 100% sure that any part of our automation is correct even though it is coming back "successful". Any help would be appreciate on what automation we should use and what syntax will work best for the JQL queries or smart values.  

Mat Pelchat

[Trudy Claspill]

Hello @mathew Pelchat 

Welcome to the Atlassian community.

When asking for help with an Automation Rule, it will enable us to help you better if you provide the following:

1. Screen images showing your entire rule.
2. Screen images showing the details of each step, especially steps where you use smart values or JQL statement.
3. Screen images showing all the details available in the audit log from when the rule executed.

[mathew Pelchat]

Hi Trudy,

We are on an airgapped system so typing it out was the best I could do.

Value Field Change: FixVersion

Issue Fields Condition: Issuetype=EPIC

Create Variable: Variable Name" EpicDate" Smart Value: {{issue.fixversion.startDate.JiraDate}}

Added a Log Action: Date+{{EpicDate}}

Added a Branch Rule: Related Issues; Implements

Added a log action: Capability Start Date ={{issue.customfield_10230}}

Added an Advanced Compare Condition: Condition: Less than, Second Value {{issue.customFeild_10230}}

Added Edit Issue: Start Date {{EpicDate}}

What is being returned in the audit when the fixversion for the Epic is changed is it finds tha changed epic, finds the date for the "new" fixversion but does not provide a value for the capability start date and it states that the capability (TT-3 in this instance) did not match the condition.

I am not overly familiar with JIRA automation so feel a bit like throwing stuff at a wall and seeing what sticks. Any suggestions you have about a better overall rule would be greatly appreciated. 

Mat 

[Bill Sheboy]

Hi @mathew Pelchat -- Welcome to the Atlassian Community!

Without seeing your entire rule, I hypothesize you are using the Lookup Work Items action to gather those linked features, and trying to find the date from there.

Please note the lookup result is a list of work items, and the fixVersions smart value is also a list of versions...leading to a nested list of lists.  When you want the single minimum value for the startDate within all of the version lists, you may use the flatten function to combine all of the results into one list, followed by distinct to remove duplicates, before using the min function:

{{lookupIssues.fixVersions.startDate.flatten.distinct.min}}

Finally, depending upon how you are updating the other field, you may need to add .jiraDate to the end to force the formatting.

Kind regards,
Bill

[mathew Pelchat]

Hi Bill,

Thank you for that insight. This automation is currently on an air gapped system but I will try to get a view of everything we are doing. and upload it to this thread. 

in the mean time here is basically what we have done. 

Value Field Change: FixVersion

Issue Fields Condition: Issuetype=EPIC

Create Variable: Variable Name" EpicDate" Smart Value: {{issue.fixversion.startDate.JiraDate}}

Added a Log Action: Date+{{EpicDate}}

Added a Branch Rule: Related Issues; Implements

Added a log action: Capability Start Date ={{issue.customfield_10230}}

Added an Advanced Compare Condition: Condition: Less than, Second Value {{issue.customFeild_10230}}

Added Edit Issue: Start Date {{EpicDate}}

What is being returned in the audit when the fixversion for the Epic is changed is it finds tha changed epic, finds the date for the "new" fixversion but does not provide a value for the capability start date and it states that the capability (TT-3 in this instance) did not match the condition.

I am not overly familiar with JIRA automation so feel a bit like throwing stuff at a wall and seeing what sticks. Any suggestions you have about a better overall rule would be greatly appreciated. 

Mat 

[Bill Sheboy]

Thanks for that information, and...even though you cannot post images due to the air-gap environment, you could copy-and-paste the audit log details text showing the rule execution.  That may provide more context.

Until we see that...

The correct smart value for the Fix Versions field is plural, and your value is not:

{{issue.fixVersions}}

Next, please re-read what I posted earlier, as the Fix Versions field is a list, and so this smart value:

{{issue.fixVersions.startDate.jiraDate}}

Could produce a result like this, with some fake dates for different versions:

2025-10-20, 2025-11-23, 2026-01-04

When there are multiple versions in the trigger issue / work item, which one do you want to use?

[mathew Pelchat]

The goal is to get it to pull the first fix version date in the list and automatically update the start date for its linked capability. 

[mathew Pelchat]

to amend what I am now doing. 

Value Field Change: FixVersion

Issue Fields Condition: Issuetype=EPIC

Create Variable: Variable Name" EpicDate" Smart Value: {{lookupissue.fixVersions.startDate.flatten.distinct.min}}

Added a Branch Rule: Related Issues; Implements, is implemented by

Edit Issue: Start Date: Smart Value {{EpicDate}}

I can't get the actual picture of the log onto this computer but the audit states

Action details: This rule was configured with a project restriction. You can change this restriction in the "rule details" section. Only issues from the following project or project types are considered. "TT" (this is my test board)

issue condition: the following issues passed (TT-12). This is the feature I changed the FixVersion on to kick off the rule.

Log Action: Epic FixVersion Date =. This section is not returning a value

Log Action: Parent Issue is: TT-3. This is the linked capability to TT-12

Edit issue: issue edited successfully: TT-3. However, nothing populates in the "Start Date" field of the capability. 

[Bill Sheboy]

Which version of Jira are you using: Cloud, Server, or Data Center?  That impacts which fields are available.

Next for the rule you describe, the Lookup Issues smart value would not apply as you are not using that.  Instead, please try this to just get the earliest startDate from the Fix Versions in the trigger issue:

{{triggerIssue.fixVersions.startDate.min.jiraDate}}

[mathew Pelchat]

We are on Data Center. I've made a little progress with the Automation. At this point my automation is updating the capability start date to the fixversion date of the feature I am editing but it is still not pulling all the feature fixversions. 

Value Field Change: FixVersion

Issue Fields Condition: Issuetype=EPIC

Variable: EpicDate; Smart Value {{issue.fixVersions.startDate.jiraDate}}

Log Action: Date = EpicDate

Added a Branch Rule: Related Issues; Implements

Variable: FixVersionStartDates: smart value  {{triggerIssue.fixVersions.startDate.min.jiraDate}}

Log Action:  FixVersionsStartDates = {{triggerIssue.fixVersions.startDate.min.jiraDate}}

Log Action: Parent Issue is: {{issue.key}}

Edit Issue: "Start Date": {{EpicDate}}

Audit log is returning the following

Issue Condition: the following issues past (TT-5)

Log Action: Date = Epic Date

Log Action: FixVersionStartDates = no date returned here

Log Action: Parent issue = TT=1

Edit Issue: Issue successfully edited (TT-1)

[Bill Sheboy]

Thanks for confirming you are using Jira Data Center!  

I checked the documentation, and the startDate appears to not be available to automation rules with the fixVersions smart value.

issue.fixVersions

Fix versions of an issue as a list. See accesing multi-value fields.
Properties for versions include: name, description, archived, released, releaseDate

You may test this with a simple rule, first confirming that issue TT-5 has assigned Fix Versions which have a Start Date:

• trigger: Scheduled, with JQL
  • key=TT-5
• action: log

The fix versions are: {{#issue.fixVersions}}{{name}}:{{startDate}}; {{/}}

If the startDates are all empty, the rule cannot access using an issue.  Instead, you could get the field by calling the REST API endpoint with the Send Web Request action.

[mathew Pelchat]

So I got an error message when running that query. the error message says error parsing template: mismatched start/end tags: null != in template-334ec0d6-ac22-4899-8f8c-32a95483389a:1

I wrote a separate automation before trying to write this rule for the capability start date to assign the start dates of the features using their fix version dates. That rule was successful. I don't know if that has any bearing on what you are talking about with the field not being able to be edited but wanted to give a little more background. 

[Bill Sheboy]

To which query are you referring that showed the error?

The simple rule I suggested only used a query to access the single issue you showed in the log:

key=TT-5

[mathew Pelchat]

the action log specifically was where the error originated from

[Bill Sheboy]

Please copy-and-paste the text from your audit log to provide more context.  Thank you.

[mathew Pelchat]

The issue was  the error message I got (in bold above) was when I as trying to set the action that you provided 

The fix versions are: {{#issue.fixVersions}}{{name}}:{{startDate}}; {{/}}

[Bill Sheboy]

That is curious...I just tested that in a rule with Jira Cloud and it worked as expected.  This suggests that either there is something else wrong in the rule or the startDate smart value causes errors when used standalone.  Again, without seeing the entire audit log from the rule execution, there is no way for me to confirm this.

At this point, I recommend working with your Jira Site Admin to contact Atlassian Support to have them take a look.  They may see something we are missing.

https://support.atlassian.com/contact/#/

When you hear back from them, please post what you learn to benefit the community.  Thank you.