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; } } }

Destination status could not be resolved or does not have a valid transition rule.

Brian Jennings

Full error: Destination status could not be resolved or does not have a valid transition rule (with current status): (Waiting for customer - 10002)

Hello all!

I've been getting this error on a couple automation rules. The link is that they are using the same workflow. I've included a screenshot of the rule w/ more details below.

This is scheduled to run every day @ 2AM, using a JQL query of "status = "Waiting for Customer" and updated < -5d" to see if there are any tickets to act on.

Screenshot 2026-04-07 154642.png

If there are any tickets that match that JQL, then they are transitioned to "Resolved".

Screenshot 2026-04-07 155055.png

A comment is then added to the ticket to inform the customer.

Screenshot 2026-04-07 155245.png

This is a very simple rule, yet 95% of the time it errors on the transition step. However, the ticket is transitioned to "Resolved" and the comment is applied.

Screenshot 2026-04-07 155437.png

I have reviewed the ticket history & comments to see how things played out, but it's always the same. The rule errors, but if it wasn't for the alert email that I get, I wouldn't know that it errors cuz everything appears to happen that should happen.

Also, the workflow does include a transition from previous statuses to "Resolved" in all cases. I've reviewed many tickets when this happens and from what I can tell, everything is correctly set up.

I've went as far as asking Co-Pilot. After a while of asking questions and adding more & more details, as the conversation transpired, it finally came back with the following: "This Jira Service Management automation error is confusing but actually very common, and it usually does not mean your rule is broken."

Using Co-Pilot was helpful, but most of the things it suggested during the convo were things I ended up ruling out and I feel like I'm not a whole lot closer to a firm answer.

Any thoughts, questions or suggestions would be welcome as I am at a loss to explain it, thx!

Accepted answers

Alan Bruce

@Brian Jennings I have had this happen before as well. It was usually due to something else transitioning the status before the Automation rule gets to it.

Check the History tab to get the timestamp of the transition and then check your Automation Audit log using the Custom date filter.

Automation Audit Log.jpg

All comments

Joseph Chung Yin

@Brian Jennings -

Have to check the actual WF supporting the JSM issue type to ensure the transition doesn't have any other conditions or validation or post function that may causing the error in the automation rule?

Hope this helps.

Best, Joseph Chung Yin

Trudy P Claspill

Hello @Brian Jennings

You said in all cases there is a transition to Resolved from the starting status. Is there more than one transition available from the starting status to resolved in any of these cases?

Do you have bespoke transitions to Resolved and a global transition to Resolved?

What are the project types of the projects that experience the error?

You said they use the same workflow. Are they actually sharing a workflow or do the use separate workflows that are designed identically?

What is the scope of the automation rule? Is the project scope for the rule a single project, global, or a list of projects? Do you have multiple rules that could be trying to perform the same steps on the same issues?

Arkadiusz Wroblewski

Hello @Brian Jennings

That’s only my suspicion, but the rule is probably transitioning successfully on one path while Jira Automation is still logging an error because the transition setup for that status is ambiguous or restricted enough that another evaluation path is failing. The comment still appearing afterward is not surprising, because Automation currently does not stop the rest of the rule when one action fails.

Brian Jennings

Hey Trudy!

Here's the workflow diagram. This workflow does not contain any global transitions to "Resolved". Sidenote: This workflow was created by the original Jira vendor with whom we partnered. It looks messy, yes, and I'm not sure it is best-practice or not. I'm not sure why they added a "Work in Progress" status when you already have "In Progress".

Screenshot 2026-04-08 092430.png

With the comment that I originally made, I just meant that there are valid transitions from previous statuses to "Resolved", which you can see in the workflow above.

Screenshot 2026-04-08 101349.png

This one workflow is used with a few Request types (including Service Requests & Incidents) in our main service space and is single-scope, just used in this space.

Hopefully I answered all your questions, let me know if this helps, thx!

Brian Jennings

Hey Arkadiusz,

Could you elaborate on this part "still logging an error because the transition setup for that status is ambiguous or restricted enough that another evaluation path is failing."?

Just looking for more detail to understand your point better.

Thanks,

Brian Jennings

Hello Joseph,

This is an interesting point. The transition does have rules when executed. I'll review which requests the automation rule failed on to see if there are any similarities that validate your point, thx!

Trudy P Claspill

Hello @Brian Jennings

Thank you for that additional information.

Is there more than one transition from the starting status to Resolved in any of the cases where the error has occurred? I am not able to discern that from the graphic.

Alan Bruce

@Brian Jennings I have had this happen before as well. It was usually due to something else transitioning the status before the Automation rule gets to it.

Check the History tab to get the timestamp of the transition and then check your Automation Audit log using the Custom date filter.

Automation Audit Log.jpg

Brian Jennings

Hey Trudy,

This scrreenshot should be more helpful. Screenshot 2026-04-10 104951.png

Brian Jennings

Alan,

Thanks for your suggestion. When you first suggested this, there were other factors/evidence that didn't make this solution appear to be the fix. Although, enough has transpired, that I now believer that you were correct with your suggestion.

It turns out that the Customer Notification SLA was being breached and causing an automation rule to trigger and changing the status. Later, the Time to Resolution SLA would breach and cause the same action and throwing that error. It took some time to put all the pieces together and realize that was the case. Given that there is a good possibility that agents may not update the customer and then not resolve the problem soon enough, I ended up editing the automation rule with an If/Else statement to accommodate this possibility.

I really wish that when looking in the history tab of a ticket, when automation rules affect a ticket, that the history would actually mention/link the exact rule that ran against it. That would be extremely helpful when diagnosing what is going on.

Alan Bruce

tracking down the automation rule that ran is a pain the keester.

I added a custom text field - Triggered Automation

Then I add an 'Edit Work Item fields' action that updates the custom field with this smart value --> {{rule.name}}

It is not 100% perfect, but it sure helps me dial in a bit quicker. Tough part is adding this action manually to all of the 200+ automations we have in place.

Give it a try if you want!

:-)

Welcome!

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

Quick Links

Find more posts tagged with

cloud

automation

jira-service-management-cloud

jira-service-management