Jira automation not affecting linked JPD issue

[Glenn A]

Hi folks-

I'm running into automation problems, hope someone can help me unwind this and that it's not a gap in Atlassian's features.

I have JPD roadmap issues that are linked to delivery tickets (epics) in other Jira projects. When the linked epic changes state (e.g., backlog to WIP), I want the originating JPD linked issue to also change its workflow state. I created a (global) automation in the delivery issue's project to 'push' the state change to the linked parent but it returns the "NO ACTIONS PERFORMED" "SOME ERRORS" status.

(I've continued tweaking the rule's owner/actor and now get an error, specifically: "Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric status ID or untranslated name for issues (with current status)." I am getting the feeling that a JPD issue's Status field cannot be changed through automation triggered from a Jira issue... has anybody done this successfully?)

I'm an org admin. What am i doing wrong?

Thanks!

[Gary Spross · Accepted solution]

@Glenn A , here's a video of Atlassian walking through the creation of an automation rule that transitions an Idea when a linked (via the "Implements" link type) is transitioned.

The "Some errors" indicating "Destination status could not be resolved" usually indicates that you are trying to transition to a status that is unreachable from the issues current status. Make sure whatever status the issue is in, is able to transition to the status you are trying to set it to.

If you don't think this is the issue, can you share screen captures of the automation rule you've configured and the workflow you have in your JPD project? 

[Glenn A]

@Gary Spross thanks for the link. My rule is similar (see post above). I went ahead and duplicated the rule in the video and it also failed.

What actually ended up working is this:

1. MUST specify trigger issue state... open ended won't work

2. MUST specify linked issue state.. copying from trigger issue won't work.

3. Would not work when actor = Jira Automation, had to run it as me.

4. I changed linked issue type to "implements" as a best practice.

It works... but not the same way as Atlassian's demo video? Also, less efficient as now I need to specify branches (or new rules all together) to handle all the different permutations.

[Gary Spross]

I agree it's inefficient and cumbersome to have to configure it this way. It's a glaring reason Team-managed projects are more of pain point than any benefit they may provide. I really wish Atlassian would provide JPD in a Company-managed style. It would avoid a lot of these headaches. I'm saying this from a customer perspective though. Not the engineering perspective that would have to build it out on that platform.

[Jeny Stoeva]

Hey @Glenn A , You need to use a Global automation rule and here is the workflow.  

[Glenn A]

@Jeny Stoeva

Sorry buddy, that is EXCTLY what I have and it does not work.

[Jeny Stoeva]

@Glenn A ,

What is important to know is that you can have two statuses with exactly the same name but they can belong to different projects! You may have selected a status which belongs to another project and not to your JPD project (where you ticket is) and unfortunately there is no way to distinguish in the list which one belongs to which project.

I saw now that you shared the error you are getting. It tells you exactly that, you are using a status which is not from the project of the ticket you are attempting to transition. It cannot resolve the status because there is no such status in this project.

[Gary Spross]

@Jeny Stoeva, I was thinking that initially as well, but I don't think statuses are impacted by the issue of the projects being of the Team-managed style (and therefore being duplicated in the select list). I say this because I have the same status name utilized in several JPD projects and Company-managed projects, yet I only see the status value once in the options list for the Transition Component.

I know the issue your explaining affects custom fields. That's been a big pain point for us having the same field name should repeatedly and not knowing which is associated to which project. In that case, when editing the values of field, best practice is to write the json in the advanced section of the edit issue Component.

[Jeny Stoeva]

@Gary Spross You are right that duplication only happens for custom fields, I just checked but @Glenn A 's problem is still that the status cannot be resolved and the reason is that he has selected a status which is not from the project where the linked ticket is.

It is literally like 404 Not found 

[Gary Spross]

@Jeny Stoeva , I don't disagree that what you state could be the problem, but I'm thinking it's more likely that @Glenn A is attempting a transition to a status that can't be transitioned to based on the configuration of the projects workflow. In this case, he would encounter the "Destination status could not be resolved" error. We won't know for sure unless he shares a screen capture of his workflow and the automation rule.

The main reason I don't believe it's a duplicative status issue is because I have duplicated statuses in my instance and I tested creating a rule to perform a transition within a JPD project. I did not see any duplicated statuses in the selection list of the Transition Component.

[Glenn A]

For context, I'm doing this in a personal trial setup (call it a sandbox) before attempting in production at work, so I've created multiple projects across JPD and Jira to sort out the correct settings.

That said, the workflows across both the JPD and Jira projects has 2 states with the same names and conditions (transition in from any): both JPD and Jira project have "In Progress" and "Done" states with "Any" transitions.

I have both the JPD issue and the linked deliver issue in the "In Progress" state. I get the error when I transition the linked delivery issue to Done.

I am the owner of the global automation and it is running as the Jira Automation user.

Here's the screenshot:

Thoughts?

[Gary Spross]

Don't select "Copy From Trigger Issue". Instead, explicitly select the "Done" status.

Try that first and see if it works. If it does, then you will need to include if conditionals to transition to "In Progress" or "Done" based on the status the delivery ticket was transitioned into.

[lila]

Hey Glenn if you just want the epic to be considered as the trigger for transition you will need to specify this too. Could you share a photo of the rule you are trying to do, this is easier to spot any potential issues. 

[Glenn A]

@lila screenshot posted

[lila]

You are missing the to status on the trigger
ie 


You need to ensure that the to status that you choose does exist on your Jira workflow.
And similarly that your destination status on the Then transition the issue to exist in your JDP.

Also that automation only work for company managed project, if you are on a team managed project it doesnt work.  

https://support.atlassian.com/jira-cloud-administration/docs/configure-workflow-triggers/ 


Currently, you can't configure workflow triggers for team-managed projects. The instructions on this page apply to company-managed projects only.

[Alex Ortiz]

@Glenn A 

Jira's JPD issues aren't "parents" of the Jira Software issue.  It looks like it is within JPD, but it's not.

What you may want to do is whenever the delivery ticket is created, a link between that delivery ticket and your JPD ticket is established by Jira.  I would use the branch rule of linked issues to take action on your automation rule.  When you do this, you want to make sure you pick the correct linked issue type, in my case, when I created the delivery ticket, the linked issue type was called Implements.  So, maybe use that one?  But definitely not parent.

Hope that helps!

[Glenn A]

@Alex Ortiz 

I believe I already tried that... didn't work. (FWIW, I used parent in the figurative sense of the word, not the actual technical sense, original question updated to remove the term. apologies for any confusion.)