Updates to how Jira fields are processed by Atlassian Automation

[#1]

Update: December 1, 2023

Since rolling this out, a few of you have reported some edge-case scenarios that we hadn't previously known about, especially around team-managed projects.

Because these scenarios are having a significant impact on your projects, we've decided to roll back this feature until a later date to ensure your automation rules continue running. We'll re-launch this feature once we've fixed these issues.

In the meantime, we still suggest reviewing the field configurations for your projects.

If you're impacted by AUTO-778 and are still interested in the performance improvements mentioned in this article, you can opt-in by contacting Atlassian Support.

Thanks for your patience as we continue working on this!

Hi Atlassian Community!

We’re posting here with an update on how issue fields work in Jira automation. This is particularly relevant to automation rules that interact with issue fields; for example, the Edit issue action or the Issue fields condition. 

What did we change?

Just a heads-up that this explanation will get a bit technical, so please skip to the How does this affect me? section if you aren’t interested. But if you’re curious about how things work under the hood, feel free to read on.

In a nutshell, we changed the API that Jira Automation uses for rule executions. The Automation platform previously used the Get fields API to process changes to Jira issue fields. However, we heard from you that this made automation rules very slow, especially when processing changes to lots of issues.

To fix this, we switched to a new API that allows for faster rule executions. This new API is much more effective at retrieving data from, and processing changes to, Jira fields - leading to faster rule executions, especially for rules that run over a large number of issues.

The new endpoint aligns with the Jira configuration model, rather than working around it, which allows the endpoint to be much more performant and thus work at greater scale, including for Jira sites with thousands of custom fields.

How does this affect me?

The previous API allowed automation rules to edit any and all issue fields, regardless of whether or not those fields existed in that issue’s project. However, this new API is more selective about which fields can be edited.

This means that when configuring an automation rule, if you select a field to edit, but this field isn’t configured in the issue’s project, the field won’t be updated.

If this happens with your rules, note that this doesn’t mean the entire rule run failed - your rule will still do everything else.

So for example, if you have an Edit issue action that updates the following fields:

• Summary (configured in your project)

• MyCustomDate (not configured in your project)

The rule will successfully update the Summary field, but not the MyCustomDate field - and an error will be raised in the audit log.

What should I do?

If you’re seeing these errors in your audit log, there are some options available to you:

• Reconfigure your rule so that only fields that are applicable to your project are used.

• Add those fields to your project, so that the rule edits those fields successfully.

• In Rule details change the Notify on error field so that you don’t get emailed when the errors are raised. This is ideal if the field is only available in some projects, and you’re okay with the rule raising errors in other projects.

To learn more, please see these resources:

• Customize an issue's fields in team-managed projects | Jira Software Cloud | Atlassian Support

• Customize request fields in team-managed service projects | Jira Service Management Cloud | Atlassian Support

• Configure a custom field | Atlassian Support

• Configure custom field context | Atlassian Support

[Andrey Kiyanovsky]

Thanks for the update. Could you please clarify what you mean by "a field configured in your project"? Let's say we have an a field that should not be visible to end users because it's a technical field for automation. In this case, we can add it to the edit screen and not add to the view/create screens. Will it work? 

In other words, the API parameter "overrideScreenSecurity" is no longer available in the A4J, is it correct?

[Kevin Bui]

Hey folks! For anyone following this page - we've decided to roll back the release of this feature. Please see the announcement banner at the top of the article.

Thank you for your patience as we continue working on this!