nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Screenshot 2024-12-19 at 04.34.38.png Screenshot 2024-12-19 at 04.35.35.png

Accepted answers

All comments

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.

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
Screenshot 2025-01-07 at 16.41.01.png Screenshot 2025-01-07 at 16.42.23.png

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation

jira-automation

cloud-automation