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; } } }

Automations "can not find configured field" suddenly

Erin Blomert

Hello,

My automations that have worked for 6 months now have suddenly started returning errors this week. The issue condition in the audit log is "Could not find your configured field, it may have been deleted?". The check to see if the field is empty and then set a value if that is the case, so very simple.

However the field is still there and functioning normally. I tried deleting and remaking that step of the automation, but it started failing again the next day. This has started to happen with multiple custom fields of different types - drop down, paragraph, and short text. Checklist type custom fields do not seem to be affected.

Has anyone else been having trouble? I'm guessing some internal update has done this.

Accepted answers

Guilhem Dupuy

Hello @Erin Blomert ,

I know that such an error can be returned when the name of the custom field is updated by an Admin; now if no Admin is regularly renaming custom field this shouldn't happen.

Another possible explanation could be with your Atlassian licence payment; if you're late on your licence renewal it might first cause some unexpected errors like the one you are facing, which are followed by the sudden loss of access to your instance afterwards, you could check that too !

Bill Sheboy

Hi @Erin Blomert

Would you please provide an image of an example rule you see failing? That may provide some context for the community to help you. Thanks!

We noted an open defect related to the behavior of JQL and IS EMPTY, so I wonder if the work on that issue is cause problems. (For that defect, a field which had a value and was cleared cannot match IS EMPTY; Jira is making the technical distinction between BLANK and EMPTY.)

Best regards,

Bill

Erin Blomert

@Bill Sheboy @Guilhem Dupuy

Thanks for your help trying to figure this out. I put off sending in a ticket for another day, and the issue has mysteriously resolved itself with me changing nothing. I think something behind the scenes changed, and then was fixed.

All comments

Guilhem Dupuy

Hello @Erin Blomert ,

I know that such an error can be returned when the name of the custom field is updated by an Admin; now if no Admin is regularly renaming custom field this shouldn't happen.

Erin Blomert

@Guilhem Dupuy The field was definitely not updated by an Admin. I can't imagine our payments are late either. Very strange...

Edit: No payment issues.

I can't seem to fix the error, even if I remake the automation

Bill Sheboy

Hi @Erin Blomert

Would you please provide an image of an example rule you see failing? That may provide some context for the community to help you. Thanks!

Best regards,

Bill

Erin Blomert

Hi Bill, I was indeed using "IS EMPTY". In fact, all my rules that have failed are using "IS EMPTY". here's the portion of one rule that is causing the problems:

Bill Sheboy

Gotcha... What type of field are you testing for IS EMPTY?

As a work-around for text fields, we are checking length for zero. For example for Description: {{issue.description.length()}}

Erin Blomert

Your workaround would work for the text fields I am having trouble with! I can set that up. Thanks.

The field in the example above is actually a drop down list, so I'm not sure how to work that one. It's kind of ridiculous for them to all stop working one day.

Erin Blomert

@Bill Sheboy @Guilhem Dupuy

Guilhem Dupuy

Okay good to hear @Erin Blomert , that was definitely an unexpected error and it's nice to hear that it was resolved so quickly !

Have a good day !

Erin Blomert

Oddly enough, another field has started failing instead.

This one creates a clone task from a service desk task to a software task. One of the fields it is supposed to transfer over now gives the "could not find configured field" error, and NONE of the values transfer over. This happens for... about 1/5 executions. Seemingly randomly.

I'm hoping that it will go away by itself too.

Bill Sheboy

Hi @Erin Blomert

Without seeing details of your rule that is failing, I offer two suggestions:

1) If this is using a Created Issue trigger, there could be a timing issue with data availability. Those can sometimes be addressed with a Re-fetch action. The "could not find configured field" message is puzzling though, so...

b) Perhaps something is glitched in the field configurations for your instance. I encourage to you submit a support ticket to Atlassian to see if they notice something the community isn't: https://support.atlassian.com/contact/#/

Best regards,

Bill

Mia Dinh-Akhtar

It looks like I'm running into this same issue now. Has this been fixed for you @Erin Blomert ?

This is my query where IS EMPTY seems to be bugging out

Screen Shot 2021-08-02 at 10.55.35 AM.png

Bill Sheboy

Hi @Mia Dinh-Akhtar -- Welcome to the Atlassian Community!

Please consider creating a new question and linking to other ones. That will help other people find the question more easily and allow you to decide when it is resolved/accepted. Thanks!

For your post, you note "my query where IS EMPTY seems to be bugging out". What are you observing?

Epic Link is a custom field (a built-in one), and there are at least 2 open defects around NOT EMPTY tests. I wonder if your field had a value, and was then cleared, causing this result.

Best regards,
Bill

Erin Blomert

@Mia Dinh-Akhtar Honestly mine just stopped failling after a week or two - I did not end up finding a solution but I would say the bug that was causing the failures must have been resolved in the background.

Michael Hill_vwmzpy

Edit (2023-12-20):

As @Rares Finatan mentioned, the solution below does not seem to be working. Not sure if we missed something during testing, but this definitely isn't sufficient. We've reverted to just dropping the "Issue fields condition" and converting it to an "Advanced compare condition" using smart values. We still seem to be avoiding the error this way, and then we can use additional filtering to narrow down to the projects we care about. Not perfect, but works.

@Bill Sheboy also has a good side note below to be aware of if you're running into a similar problem.

Original answer (2023-11-22):

For anyone else who comes across this, we ran into a similar issue today. Some notes/caveats:

We have a global automation running into this error, triggering lots of emails.
The error is occurring on an "Issue fields condition" for a custom "Team" field. This field is present in our organization's default field configuration.
The errors only started last night (2023/11/21) and for team-managed projects only. We're not aware of any changes that could have triggered this, so suspect an Atlassian backend change -- possibly impacted by Jira Cloud's recent changes to their own "Team" field.
Error message: "Could not find your configured field, it may have been deleted, or may need to be added to the project"

The problem seems to be the field not existing in the project field configuration. Since team-managed projects don't use shared field configurations, it makes sense that it's not present. However, both the automation and the problematic projects are very active/mature, so it's unclear why the errors only started last night...

The solution for us was pretty simple: create a new "Advanced compare condition" to check if the field exists. Docs: Jira smart values - conditional logic.

2023-11-22 12_39_07-Automation - Jira.png

Bill Sheboy

Hi @Michael Hill

As that rule is using a combined trigger of Issue Created or Issue Assigned, this symptom could also be a timing issue.

The Issue Created trigger can fire so quickly the issue data is not yet available to the rule. This can result in later rule steps working unexpectedly and false-positive errors for field problems. The work-around / fix for this is to always add the Re-fetch Issue action immediately after the Issue Created trigger. That will slow the rule by about one second and reload the issue data before proceeding.

Kind regards,
Bill

Rares Finatan_jop9tq

Hi @Michael Hill - I've started seeing the same errors pop up, seemingly randomly. I'll try your fix - thanks for bringing this topic some recency!

Update: Attempted your fix, but no actions were performed on that basis that my custom field suddenly no longer exists and doesn't pass the exists check. Odd how it was working for months on end, but suddenly fails to recognize it.

Michael Hill_vwmzpy

Updated my original post. I'm not sure if we just didn't test this well enough, or if there was another change under the covers, but this isn't working for me either now... Converted to a different solution -- not perfect, but at least seems to be working.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

atl-gruland

automation