Task Automation rule fails with 'invalid field' error in Team-managed project

[Thu Nguyen]

An automation rule in a Team-managed project is failing with the error 'Additional fields contains invalid field(s) in update or fields section. Story point estimate'.

The project is Team-managed, and the rule uses the default field 'Story point estimate' in the automation JSON:

{
"fields": {
"Story point estimate": {{#=}}{{QA Story Point Estimate}}{{/}}
}
}

The rule previously worked but now fails. The user has confirmed that the field is present and is using the correct field key for Team-managed projects. Please investigate and advise.

[Dorian ALEXANDRE · Accepted solution]

Hello,

Have you tried using the custom field ID instead of its name?

Here’s an example:

{
"fields": {
"customfield_xxxxx": {{#=}}{{QA Story Point Estimate}}{{/}}
}
}

[Thu Nguyen]

This is default field not custom field

[Thu Nguyen]

I tried with the customfield_16486 ID
Jira continues to send an error message, but actually, it worked. Work is still better than not working at all. Thank you

Please note that my previous format has worked for a long time, and in "Beautiful Day", it doesn't work anymore (I checked, and no one changed it)
{
"fields": {
"Story point estimate": {{#=}}{{QA Story Point Estimate}}{{/}}
}
}

[Bill Sheboy]

Hi @Thu Nguyen -- Welcome to the Atlassian Community!

The community needs context for automation rule questions to provided better suggestions.  Please post the following:

• an image of your complete rule in one single image for continuity
• an image of the complete Edit Work Item (or Create Work Item) action where you use that JSON expression
• an image of the audit log details showing the rule execution with the error
• an image showing all the audit log entries including cases where the rule succeeded in the past

Until we see those...

There are several possible causes for that symptom:

1. The field value for "QA Story Point Estimate" cannot be interpreted as a number
2. Someone has changed the rule, and the action has an error for other reasons
3. Someone has altered the field, "QA Story Point Estimate".  Smart values are name, spacing, and case-sensitive...and, the smart value does not always match the field name displayed on the views.  Try using the custom field ID for that field instead, which you may find with this how-to article.
4. The rule has "glitched".  This can happen when a rule has been updated / published too many times.  The way to check for that is to disable this rule and re-create it from scratch.
5. Someone has added a duplicate field named "Story point estimate" at a global scope and added that to the team-managed project, and so it is colliding with the existing one

Kind regards,
Bill

[Thu Nguyen]

[Bill Sheboy]

Thanks for that image, and did you check the possible causes I noted above?

Please also show the audit log entries of all executions to show where the rule worked in the past and when it stopped working.

[Gor Greyan]

Hi @Thu Nguyen

Welcome to the Atlassian Community!

In Team-managed projects, the field “Story point estimate” only exists if estimation using story points is enabled.
If estimation is turned off or changed (for example, switched to “Time tracking”), Jira will throw that error.

If it is enabled, try this one in Additiona Fields section.

{
"fields": {
"Story point estimate": {{#=}}{{issue."QA Story Point Estimate"}}{{/}}
}
}

[Thu Nguyen]

I tried but it didn't work 

[Gor Greyan]

Hi @Thu Nguyen

Did you receive an error message?

Could you please share the audit log?

[Thu Nguyen]

It continues to fail with "Story point estimate". I failed with the "Story point estimate" field, not "QA Story Point Estimate"

After I changed to Field ID, it looks better and works

[Gor Greyan]

Hi @Thu Nguyen

That’s great to hear — thank you for confirming! 🎉

Yes, in Team-managed projects, Jira sometimes handles certain fields (like Story point estimate) differently under the hood. When using automations, referencing the field ID instead of the display name ensures Jira maps the field correctly, especially if the project uses a different estimation method or localized field name.

I’m glad switching to the field ID worked for you — that’s definitely the more reliable approach in these cases.