Have a really weird issue I've been trying to figure out with automation. Here is the workflow we have: * A "spec task" issue type is created. An automation will create an epic alongside of it and link the spec task type issue to the epic and copy over relevant fields. One of these is Amtech Engage case number field. * An "RFE Coding" issue type is created at a later time. I want to look in Jira to find the epic to find one where the Amtech Engage Case Number field matches the value of the same field in the RFE Coding ticket. * I have an automation that is running on issue create. Added an if statement for Issue Type = "RFE Coding" Then I do a lookup issues to find issues where the issuetype = Epic and the Amtech Engage Case Number field ~ the issue.customfield_10344 value #3 is where the issue lies. I have run the scenario through in my sandbox Jira instance and had no issues. When we activate it in production, I get an error saying "unable to find any issue field values to edit." I have also added logging to see if I'm getting a value back from my lookup query. This is where it gets strange - the log returns nothing in production, but in sandbox I get a value back. Below are screenshots of my rule setup first in Sandbox, then production, then a screenshot of my latest run with errors. Could anyone help out with what could be causing a difference in production vs. sandbox?

I haven't had a chance to test the last one yet about adding the JQL to the audit log but will update here as soon as I do.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

lookupIssues not returning any values in production, but does in sandbox

Zach Handzlik

Have a really weird issue I've been trying to figure out with automation.

Here is the workflow we have:

A "spec task" issue type is created. An automation will create an epic alongside of it and link the spec task type issue to the epic and copy over relevant fields. One of these is Amtech Engage case number field.
An "RFE Coding" issue type is created at a later time. I want to look in Jira to find the epic to find one where the Amtech Engage Case Number field matches the value of the same field in the RFE Coding ticket.
I have an automation that is running on issue create. Added an if statement for Issue Type = "RFE Coding" Then I do a lookup issues to find issues where the issuetype = Epic and the Amtech Engage Case Number field ~ the issue.customfield_10344 value

#3 is where the issue lies. I have run the scenario through in my sandbox Jira instance and had no issues. When we activate it in production, I get an error saying "unable to find any issue field values to edit."

I have also added logging to see if I'm getting a value back from my lookup query. This is where it gets strange - the log returns nothing in production, but in sandbox I get a value back.

Below are screenshots of my rule setup first in Sandbox, then production, then a screenshot of my latest run with errors. Could anyone help out with what could be causing a difference in production vs. sandbox?

Screenshot 2025-03-17 at 4.34.00 PM.png

Accepted answers

All comments

Bill Sheboy

Hi @Zach Handzlik

The Issue Created trigger has a known racetrack / timing problem where the rule can start before all of the data is available to it. As a result, your condition and lookup issues JQL could be missing data when the rule runs.

The mitigation for this is to always add the Re-fetch Issue action immediately after the Issue Created trigger. This will slow the rule a bit and reload the data before proceeding.

If that does not solve the symptom...what is the type of your custom field, Amtech Engage Case Number: text, number, a select-option field, etc.?

As written, the JQL would work for text or a number field. When it is a select-option field, add .value in the JQL expression to use the selection.

Kind regards,
Bill

David Friedrich

Hi @Zach Handzlik ,

It sounds like there is a difference in field availability, permissions, or indexing between sandbox and production.

Here's how I'd try to debug this:

Verify the field data exists in production. Run this JQL manually in production to see if an Epic with the expected field value exists:

issuetype = Epic AND "Amtech Engage Case Number" IS NOT EMPTY

Then look for a direct match:

<span>issuetype = Epic AND "Amtech Engage Case Number" = "KNOWN_VALUE"</span>

If no results appear, the field may not be indexed or be available for Epics.

Hence check the context & configuration of the custom field. Ensure:

The field is available for Epics.
The field is not restricted to certain projects.

Also just make sure to check the permissions for the automation rule and ensure the Automation rule actor can:

Browse Projects
View/Edit Issues
Access the Amtech Engage Case Number field

Also when adding debugging logs to the rule, before the lookup, log the field value in the RFE Coding issue:

<span>Log action: "RFE Coding Case Number: {{issue.customfield_10344}}"</span>

After the lookup, check if any issues are found:

<span>Log action: "Found {{lookupIssues.size}} matching Epics"</span>

Let me know what you find from these steps!

Zach Handzlik

Hi @Bill Sheboy thank you for the suggestion. I added the Re-fetch action right after the issue created, but unfortunately this didn't work. I moved it to after the if statement to see if that helped, but that didn't work either. I also don't think that was the issue either as the issue doesn't appear to be with finding the case number value. As you can see in the audit log screenshot that the value of the amtech engage case number is being successfully fetched. The issue lies in the "lookupIssues" command. It is returning 0 results.

To answer your question, it is a text type field.

Zach Handzlik

Hi @David Friedrich ,

Thanks for the suggestion. I didn't mention in the original post, but I was able to manually run the JQL query by just searching for the matching value of the Amtech Engage Case Number known value. Also, I have your suggestions of audit queries implemented as well. Here is the screenshot of that: Screenshot 2025-03-17 at 5.18.04 PM.png

Bill Sheboy

Thanks for that information, and...

I recommend writing the JQL you are trying (with the smart value in place) to the audit log, running the rule, and the checking the log to confirm the JQL contains what you expect.

Bill Sheboy

Hi @Zach Handzlik

Just following up if the suggestions resolved your question. If so, please consider marking them as "answered" to help others with similar needs find solutions faster in the future.

If not, please respond with additional details so the community can help. Thanks!

Kind regards,
Bill

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation