Automation not applicable to a new project

[Dmitry Alabyan]

Greetings, Community!
I've set up a complex branched automation that is built around linked issues in the project. It triggers mathematical functions to be executed against certain fields of certain issue types if they have a specific link type.
In reality - sums up expenses from one level of issues to another in the corresponding field.
Automation is limited to one project, which has now been cloned entirely to be adapted for the upcoming 2025. Settings of the new project as well as the structure are identical to the existing and working one.
Somehow the automation doesn't get through the update though. It also had to be copied, as execution is relevant only in a single-scope.
Attached are the
a) failing step upon the validation of the copy 
b) source step working fine in the current '24 project

Any ideas?

[Bill Sheboy]

Hi @Dmitry Alabyan 

First, I would confirm the custom field exists in the new project.

Next, a Jira Work Management (JWM) project could be team-managed or company-managed.  For the team-managed ones, the custom fields are distinct for each project, and so...

When an automation rule is copied from one to another (or between project types), it could still be referencing the custom field IDs of the old project.  Another possibility is the custom field name is ambiguous when referenced between projects.

There are two things to try to resolve this:

• When the rule is clone to a new project, open the rule in the editor and re-publish it.  Then test to confirm it works.
• Rather than using the custom field name, use the custom field ID to confirm it works as expected.  To find the correct custom field ID, please use this how-to article: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Kind regards,
Bill

[Dmitry Alabyan]

Thank you, @Bill Sheboy 
Since I am managing both instances - of course, the fields do exist. As well as the projects are company-managed.

I've checked the field ID through the api call  - it's one and the same field, same ID.
Hence, I do not also see the collision (ambiguity) in names - I am applying the same logic to the same field.

Lastly, the rule itself is not cloned. Automations are not duplicated through DeepClone.
Rather, I manually cloned it and set the scope to be for a) two projects instead of one
b) new project only - hence, also confirmed the issue lies somewhere with the new project.

[Bill Sheboy]

Please post the following:

• An image of your complete rule, in one single image file.  This will provide overall context.  If your rule is larger than a single page, try using a screen capture tool or browser addon which supports scrolling page capture.
• An image of the complete Edit Issue action where that JSON is attempted.  Only part of that action is currently shown.
• An image showing the audit log details (if the rule was able to execute)

[Dmitry Alabyan]

- the rule has got these branches in it, overall 8, with a difference only in the linked issue step, since it's very specific for each branch.
- JSON advanced edit is actually complete, nothing else happens
-  audit log - N/A, rule doesn't save with these specs, so we don't even get to the execution part

[Bill Sheboy]

Thanks for those images.

You noted you checked the field's ID to confirm it.  Did you also note the capitalization exactly matched what you are using for the smart value in the JSON?  If it does not match that will not work.

Regardless, let' try the custom field ID in place of the smart value for the "Budget Spent" field.  Please substitute in your specific field id value.

{
  "fields" : {
    "customfield_12345": "{{lookupIssues.customfield_12345.sum|0}}"
  }
}

And if the custom field is a number-type, please remove the quotation marks in the JSON for the value:

{
  "fields" : {
    "customfield_12345": {{lookupIssues.customfield_12345.sum|0}}
  }
}

As an aside, there is a change rolling out this week adding better validation to rules.  I wonder if that is causing this symptom:

https://confluence.atlassian.com/cloud/blog/2025/01/atlassian-cloud-changes-dec-30-to-jan-6-2025#:~:text=Validate%20more%20components%20in%20Jira%20and%20Confluence%20automation%20rules

[Trudy Claspill]

Hello @Dmitry Alabyan 

What is the Type of these projects? You can get that information from the Type column on the View All Projects page under the projects menu.

What process did you go through to "clone entirely" the project?

[Dmitry Alabyan]

these are work management ones.

Cloning - used the deepclone plugin.