Jira automation rule can't get dates from lookup issues from Epic partition branch

[Frankie J]

I have read many threads and tried every combination I could fine but can't simply get dates from {{lookupIssues}} in my branch for the Epic parent when my trigger issue (Story) changes.

Things that do work for my Jira Automation Rule:

• After issue change, I can read/access all dates of interest for the issue using custom ID or logical name using the following:  {{issue.customfield_XXXX}} or {{issue.Start Date}}  Note: I use the Add to Log feature to verify this.
• In the Epic (parent) Branch, I can get the trigger issue dates easily by using either of the following commands: {{triggerIssue.customfield_XXXX}} or {{triggerIssue.Start Date}}
• In the Epic (parent) Branch, I can easily add a list of all the issues for the parent using to my rule log using the following:  {{lookupIssues}}
• In the Epic (parent) Branch, I can easily log the count for the number of issues by using: {{lookupIssues.size}}
• In the Epic (parent) Branch, I can easily log the First and Last issue id by using: {{lookupIssues.first}} or {{lookupIssues.last}}

Things that do not work for my Jira Automation Rule:

• {{lookupIssues.first.Start Date}} OR {{lookupIssues.first.customfield_XXXX}} 
• I tried adding .jiraDate to the above.
• I tied adding .format to the above and stuff like that.
• I made sure that the issue found for First or Last has actual dates and not empty fields.
• I have tried to use the .min and .max properties

Help! :)

[Babar Brohi]

I’ve run into the same limitations with Jira Automation and {{lookupIssues}}. Unfortunately, {{lookupIssues.first}} and {{lookupIssues.last}} return issue objects in a limited context, and accessing fields like Start Date or custom fields directly on them doesn’t work the same way as with {{issue}} or {{triggerIssue}}.

A workaround that tends to work is to use the “Re-fetch issue data” option in your branch or to iterate through {{lookupIssues}} using a smart for loop in your log/conditions and then reference each issue’s fields individually, e.g.,:

{{#lookupIssues}}

 {{Start Date}}, {{customfield_XXXX}}

{{/lookupIssues}}

This will give you all the dates for the Epic’s child issues. Then you can apply .min or .max outside the loop on the collected values.

Others have mentioned that sometimes the automation engine doesn’t resolve nested fields on first/last objects, so using the loop approach is more reliable.

[Bill Sheboy]

Hi @Frankie J 

For a question like this, context is important for the community to help.  Please post the following:

• what version of Jira are you using: Cloud, Server, or Data Center
• for Cloud, what type of project is this: company-managed, team-managed, JPD, etc.
• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution
• explain what is not working as expected and why you believe that to be the case

Until we see those...

Without knowing your Jira version, I wonder if you are using Jira Server or Data Center, as those only have a limited number of supported fields in the Lookup Issues action results:

https://confluence.atlassian.com/automation/jira-smart-values-issues-993924860.html#Jirasmartvaluesissues-lookupissues

Kind regards,
Bill