Automation issues with updating a custom field

[Jeremy Jones]

Hi all,

I created some automation to amend a list of approvers, based off the type of work item. What I have noticed is that often the automation is failing and throwing an error in the audit log, but the reason does not make sense. 

This is the error from the audit log, however the field does definitely exist and is available within the project. I know this as it sometimes works and sometimes does not - for the same work item types and within the same project. It appears completely intermittent. Sometimes it throws the above error however the automation works ?!?!?! Occasionally the users will clone a working ticket, only to have the automation fail in the new ticket.

For reference, this is the audit log for the exact same type of work item within the same project.

EDIT FOR CLARITY: I now have 3 automation rules that perform a similar function (based on what type of work item). I would prefer to have the one "main rule" once I can rectify this issue

1. The main rule

2. The Split Rule - Changes

3. The other split rule - Deployments

The Delay and re-fetch items above were added in my attempts to fix this issue as I thought it may be caused by some sort of lag issue within Jira during the status transition, where the field becomes momentarily unavailable. This has not fixed the issue

The field is a global field and is used in every project within the company - likewise with the work item(s). 

I have checked Solved: "Some of the set fields aren't available" error in... and How to Fix "Unknown Fields" Error in Jira Cloud Automation Rules | Jira and Jira Service Management | Atlassian Support but they dont appear to solve my issue as far as I can tell.

I am not very technical so I could be missing something quite simple but logically it doesn't make sense to me.

UPDATE: This is the audit log (albeit from a different project and work item type) where the audit log showed this error but the automation seemed to actually work correctly. 

ADDITIONAL UPDATE:

This is the exact same ticket having success and then failing on the same rule a few seconds later

ADDITIONAL UPDATE AGAIN:

My perception is that the issue occurs in 2 specific work item types (regardless of project) As per the evidence above, it does not always occur but all other work item types appear to be going through without issue and without throwing the error in the audit log.

I have gone through and checked between the work items that seem to fail and the work items that seem to pass:

- they appear in all the same schemes

- the "Change and Deployment Approvers" field does not show in any screens

- the "Change and Deployment Approvers" field does not show in any work item layouts

Anyone able to assist?

[Jeremy Jones · Accepted solution]

Hi all,

After careful consideration and some assistance from other smarter than myself, we tried to trigger the automation upon item creation rather than the status transition.

The thinking here was that (as mentioned here by @Sebastian Quesada Ocampo ) there were some timing/lag issues caused by the trigger being the same as the key status.

This now means that the Change and Deployment Approvers field gets populated before the field is required.

So far all the tests have been successful!

Thank you to everyone who assisted especially Sebastian who changed our line of thinking

Here is the new automation if anyone is interested....

[Bill Sheboy]

Hi @Jeremy Jones 

I am glad to learn you found a workaround, and...

There are known racetrack timing defects with the Work Item Created trigger.  This means the work item can be in an unstable state, with incomplete data as the rule starts leading to weird errors and missed conditions.  In some cases, the work item does not even have a type yet!

Atlassian knows about these defects and as of July 2025, is reportedly working on architecture changes to address them...with no release timeframe announced.

To mitigate those defects, I recommend some changes to the rule you show:

• Always add a Re-fetch Work Item Data action immediately after this trigger and before other rule steps.  This will slow the rule slightly, reloading the data before the steps proceed.
• Never use the new feature to add conditions directly to a trigger.  There are several challenges with this new feature, and timing problems with various triggers, including Work Item Created; thus, conditions in the trigger may produce incorrect results and be very difficult to debug.  Instead, add individual conditions after the above noted re-fetch action.

Kind regards,
Bill

[Sebastian Quesada Ocampo]

Hi @Jeremy Jones 

From what can be seen in the rule flow and the audit logs, the automation is correctly configured and the condition is being met. The failure occurs specifically at the “Edit work item fields” step, where Jira reports:

“Edited work item successfully, however some of the set fields aren't available”
Fields ignored: Change And Deployment Approvers

The key point here is that the field does exist and is correctly configured, as evidenced by the fact that:

• I understand that in some cases (e.g. IS-12615) the rule runs successfully
• In other cases (e.g. IS-12609) it fails intermittently, within the same project and issue type

This effectively rules out:

• Permission issues
• Field context issues
• Basic configuration errors

What may be happening is a timing/synchronization issue in Jira Cloud Automation:

• The rule is triggered immediately after the transition to Pending Approval
• Even with Delay + Re-fetch, Jira does not always finish initializing complex fields in time
• Approvers / multi-user picker fields are particularly sensitive to this
• When the field is not yet fully “exposed” internally, Automation treats it as unavailable, even though it exists

This explains why:

• Sometimes the rule fails but the issue still transitions
• Sometimes it works without any problem
• Failures are more common on newly created or cloned issues
• The audit log message is misleading

The “field not available” message does not mean the field doesn’t exist; it means it wasn’t available at that exact execution moment.

Practical recommendations to reduce the issue:

• Increase the delay (e.g. 10–15 seconds)
• Split the logic into two rules:
  • Rule 1: detect the transition and mark the issue (label/flag)
  • Rule 2 (with delay): update the approvers field
• Add a pre-condition such as field value exists / is not empty before editing

[Jeremy Jones]

Hello and thank you for your response!

I can confirm this the additional delay has not resolved the issue

I am not enitrely sure what you mean but splitting the logic...could you please elaborate on this one?

Re the third option you presented, is there automation that can check if the field exists and if not, add it?

[Jeremy Jones]

Hi again @Sebastian Quesada Ocampo 

I tried to split the rule which is what I think you meant... (please note in this example, I manually pushed the ticket through the workflow so it no longer shows as being in PENDING APPROVAL status per the automation rules)

This is the split rule

[Sebastian Quesada Ocampo]

Hi @Jeremy Jones 

Thank you for the information, that’s very helpful.

Could you please share a screenshot of how the “Edit work item” action is configured, specifically the part where the field value is being set?

[Jeremy Jones]

Hi @Sebastian Quesada Ocampo 

The "main rule" has 3 parts based on IF criteria

[Bill Sheboy]

Hi @Jeremy Jones 

Do you have multiple fields with the same name in different scopes (e.g., global / company-managed and local / team-managed), and is one of the work items showing errors in a team-managed space?  If so, this symptom can occur when the rule processing uses the incorrect field due to the rule's global scope.

To test for this cause, check your team-managed projects for a duplicate field...or edit the field in the action using JSON with the correct custom field ID rather with than its display name.

There are additional possible symptoms for this cause, such as weird things in the UX when a global field with the same name is added to a view in a team-managed space which has a duplicate field by name.

Kind regards,
Bill

[Jeremy Jones]

Hi @Bill Sheboy 

Thanks for your response

There are no other fields with similar names 

[Bill Sheboy]

Based upon that image, the field is not used in any spaces.  Is that correct?

[Jeremy Jones]

I dont know why it says that - it is used in every project that we have.

In audit logs it shows as working across different projects....

[mruttan]

First thing I would check is that the field in question has been added to the screen of the issue type(s) you are dealing with.  

[Jeremy Jones]

Hi there

Thanks for your response

The field is not supposed to be visible on the screen and has not been visible on any tickets - working or not.

Given that the field is not on the screen of proven working examples, I would assume that this is not the cause of the issue?

[Chris Rogers]

Hi @Jeremy Jones

Can you post a screenshot of how you have the rule configured in Automation, including the rule actor?  I've found that, often, depending on who the rule is running as and the state of the issue, automation can run into permissions issues.  Usually, I have the Actor of the rule set as Automation for Jira, as that account has special permissions that bypass some of these errors.

[Jeremy Jones]

Hi @Chris Rogers 

Thanks for responding!

Hopefully this is what you are asking for....

[Chris Rogers]

@Jeremy Jones, that is odd; your actor in the rule is set to Automation for Jira, which should help bypass some permission issues, but I noticed it's a global rule.  A couple of quick things I like to do are to add an audit log entry at the top of the issue when I'm actively troubleshooting.  Something like:

Work Item Type -> {{issueType.name}}, Status -> {{status.name}}

This will help determine if there's a common theme between issues that fail to update as it might come down to a field configuration or something similar.

[Jeremy Jones]

Thanks @Chris Rogers 

I have added the following to the main rule which I think it what you suggested...