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.
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 !
@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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 !
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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()}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm also not sure if it's not finding it when it does the condition, or if it's not finding it when it actually tries to input the value. If the field is not empty, it actually seems to fail the conditional correctly and the automation has no errors.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For a list field, I have not noticed those having problems with IS EMPTY tests. If you are, you can try the list functions. For example for fixVersion checking to zero for {{issue.fixVersion.size}}
Debugging automation rules can be tricky; please consider adding actions to log to the audit log. That can show you values as you progress and reveal why conditions do not work as expected.
For more debugging ideas, please see this article:
https://support.atlassian.com/jira-software-cloud/docs/debug-a-rule/
Thanks,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It's not a "list", it's a drop down where you select one of two items. I may have stated that incorrectly! I will try adding more debug statements, but my problem remains that the automation is suddenly not recognizing that the field exists, even after a remake.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No worries, and the drop-down fields are "list" fields once you get inside a rule.
At this point, I recommend you submit a support ticket to Atlassian as they may see something behind the scenes that is causing this. Here is the link to do that:
https://support.atlassian.com/contact/#/
Once you learn more from support, please consider posting back here so others in the community can benefit. Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.