How can I get a rule to affect tasks that are linked across two different projects?

[david_napoli]

I have created a rule and edited the scope to encompass two different projects. The rule is intended to update the status of two cloned tasks parallel to each other. The rule works in the two projects individually, but the parallel update will not work on tasks that are linked across the two projects. Attached below is an image of the rule I am working with. Thank you in advance for any assistance.

[Walter Buggenhout]

Hi @david_napoli and welcome to the Community!

There may be quite a few reasons why your rule may not function correctly. But the most likely reason is that the linked issues in your different projects may not be sharing the same workflow. And in that case, copy the target status from your trigger issue is more likely to fail than to succeed:

• if your projects happen to be team managed projects, the statuses in your 2 projects are different. Even if they have the same status names. In this case copy from trigger issue will never work for status transitions.
• if your projects are company managed and the issues share the same workflow, than the transition happening on the triggering issue must also be available from the current status of your linked issue. Nothing in your automation rule is in place to validate if this is the case. Suppose your trigger issues has changed from In Progress to Done, your rule can only work if your linded issue has the same transition available.
• ...

Have a good look at the project types of the projects in scope of your rule. And also make sure the workflows have similar transitions available. If so, add additional conditions to your workflow to make sure you are performing the same transitions and be more specific if/where necessary.

Hope this helps!

[Trudy Claspill]

Adding to this...

To help debug this rule please provide a copy of the details in the rule Audit Log for an execution of the Rule where you did not get the results you intended/expected. Make sure that you expand all the nested details in that rule execution log so we can view all the details of each step.

[david_napoli]

Currently I am just testing this with two blank projects with the default settings, so the statuses are the same with To Do, In Progress, and Done. Is there any other reason why this would not be working?

Thank you again for your assistance.

[Trudy Claspill]

What are the Types of the projects? Get the Type information from the View All Projects page under the Projects menu.

If the projects are Team Managed, the configurations of each project are unique to the project. While the workflow statuses may be named identically, in the backend they have unique identifiers so that To Do in on is not actually the same as To Do in the other.

[david_napoli]

This is a huge help. They are both team managed and looking at the audit log I am seeing the problem that you're mentioning. Is there a workaround for this?

[Trudy Claspill]

I don't currently have a quick/simple work around at my fingertips. There may be one available that I don't know about. All the ideas that are initially popping into my head are complicated and involve creating multiple rules.

[david_napoli]

Would a multi-rule solution entail making a rule for each status change instance? i.e. In Progress > Done, To Do > In Progress

[Bill Sheboy]

Hi @david_napoli , @Trudy Claspill , and @Walter Buggenhout 

A single rule way to probably solve this, although a bit complicated, is using a Lookup Table to get the transition ID for the destination status (based upon the project) and then use the REST API called by a Send Web Request action to perform the specific transition.

Kind regards,
Bill

[Trudy Claspill]

I knew @Bill Sheboy would have a better solution!

[Bill Sheboy]

Hi, Trudy!  To me, it wouldn't necessarily be better / worse.  I just liked the "puzzle to solve" ;^)

I do wonder about the "why" for cases like this...that is, "why would independent, cloned Jira issues need to be kept in status-sync across projects if they are truly independent work items?"  And if they are not independent, why not either:

• break the dependency so status values can independently reflect their progress
• delete any duplicated / unneeded issues

Perhaps I missed that info from the earlier posts.