You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I recently created Automation at Global Scope. When an issue is created, if there is an approver field, write a comment referring to the approver.
The problem is, when an issue is created for a project without any Approver Field, SOME ERRORS occurs for some projects and NO ACTIVIONS PERFORMED for others.
Importantly, neither project has an Approvers field. In other words, I will be fine if both become NO ACTIONS PERFORMED, but I am puzzled that some projects have SOME ERRORS.
In the case of a project where SOME ERRORS occurs, the error message below is shown.
Could not find your configured field, it may have been deleted, or may need to be added to the project
Whenever SOME ERRORS occurs, I receive a failure notification email. How can I change it to NO ACTIONS PERFORMED from SOME ERRORS?
Can you describe each step of your rule, or provide screen images (in English)?
Additionally can you provide the complete details of the rule execution Audit Log (in English)?
In order to give you advice we need to know which step is producing the error. We also need to understand the context in which that step is executing within the rule.
Are both projects Company Managed projects? If so check if the field is present in the Field Configurations used by the issue types being created.
While both projects may not have the field on the screens, the one resulting in No Actions Performed may have the field in its Field Configuration. That would enable the rule to resolve the field reference. If the field is not in the Field Configuration for the project and issue where you get the error, that could be the reason for the error.
Hi, the project that has an error is not the company managed project. this project is the team managed project. Will this be a problem?
When I see the Issue types of this project, it doesn't contain Approver field now, but it seemed like a situation that could add an approval field.
I'm having the same issue in my project:
"Could not find your configured field, it may have been deleted, or may need to be added to the project"
Everything used to work perfectly, but just out of the blue, this error started popping up. There is no delay with payments to Jira and Add-ons.
Check this screencast:
Company Managed projects use Field Configurations that can be managed by a Jira Administrator and shared by multiple projects. If the field is listed in the Field Configuration then the Automation Rule can resolve the field reference.
Team Managed projects do not use Field Configurations. Team Managed project know only about the fields that are available on the screen for that specific project. If the Approvers field is not present in the Team Managed project's screen, then you will get that error.
I watched your video. The error you are getting is related to trying to edit a a field (Checklist Text) in an issue (UPPROP-15).
If you view the issue UPPROP-15 directly do you see the Checklist Text field on the screen? And can you edit it?
If the Company Managed projects and the Team Managed project are the same type of project, for instance if they are all Software projects, then one option is to change the Rule Scope from Global to Multiple Projects. Then you have to select each project where you want to rule to be run. If you create a new project where you want the rule to be run, then you will have to update the rule Scope to include that project.
Another option is to add a Condition immediately after the Trigger. In that Condition check that the Project field of the triggering issue is not equal to the Team Managed project. The rest of the rule would then execute only for a issues in projects other than that one Team Managed project.
My suggestion was not to use a Condition to check if the trigger issue project was Team Managed or Company Managed.
My suggestion was to use a Condition to check if the Project field of the trigger issue indicates it is from the specific Team Managed project that you want to exclude:
I'm with HeroCoders, the team behind Issue Checklist Pro, one of the apps affected by this error. We had some tickets about this issue coming from different customers.
It seems that Atlassian introduced something on the backend that affected fields with global contexts but no screens associated, like our Checklist Text field.
We do not yet know the inner workings, but adding any custom field to any screen in a project and removing it re-registers the field within that project's field configuration scheme. It is confirmed to work in team-managed projects as well.
You do not need to show the field in the issue view, just add it, save, remove it, save.
This should solve the issue.
Thanks for your quick responses!
Honestly, I don't really understand how to make it work. Indeed, I use Checklist Pro, and everything used to work properly, besides, the steps you advice didn't help.
See the whole logic and attempts over there:
Is there any hope to resume the checklists in automation working?
It became apparent yesterday that the solution I proposed was very short-lived - Jira database apparently clears the field association from the scope of automation rules soon after the field is removed from the last screen in any given project.
We have started to push back against this change, please see here: https://ecosystem.atlassian.net/browse/ECOHELPPUB-95 I'd appreciate it if you commented on this ticket saying this affects you if you have access to it.
In the meantime, one of our customers came up with a workaround - they created a placeholder issue type and added it in their projects, configured it with a separate screen configuration and added Checklist Text to that screen.
They never plan to use that issue type, but it registered the field within the project and restored their automated operations related to Checklists.
I hope this helps, as ugly as the workaround may be. We are determined to help our users with this. We are sorry that there was no heads-up, but this change surprised us greatly as it was not communicated with the developer community beforehand.