Automations are slow to update Issue Type values. This leads to subsequent conditions in the same automation or separate automations to fail.
Automation "A" is designed to update the issue type field from Type 1 to Type 2. The automation audit log says that the update is taking a long time but it believes that is done. An automation Log Entry action still shows Type 1 as the issue type.
UPDATE: The above screen shot is missing a refetch in the rule. I considered removing it but never published the change. Unfortunately the screenshot was taken when the refetch was removed. It occurs between the Edit Issue Type and Log actions.
Automation "B" has a trigger of Issue Type Updated. I see the issue from Automation "A" hitting the trigger telling me that the issue type change has been logged. However, the condition to validate that issue type is set to Type 2 fails.
I previously had all of this in a single automation but it was not consistently working. Created separate automations to make sure the issue type was properly set before moving to next steps and it seems that is failing. Curious if this is a performance issue with cloud or the automations themselves. Pure speculation: It seems like the updates are happening on one server while the conditions are being read from a separate server and the replication delay is causing the conditions to fail. Please halp!
I have several thoughts on what you're experiencing.
The community (and I) would be interested in learning what eventually works for you. Hope some of the above helps. Good luck!
Thank you for your ideas! Sorry for the confusing screenshot, I had considered removing the refetch and what you are seeing is it removed from the rule but I never published that change. Here is what it looks like:
So, the re-fetch is part of the automation. The "slow to respond" is coming from the first action of editing the issue type. The screenshot of Step 1 shows that the audit log entry after the re-fetch still shows the original issue type.
The slow to respond message has showed up several times in different automations. Ultimately it appears that the action has taken place but it looks like the API call took longer than the limit on getting a response. I wish that I had control over that because I would increase the limit time so I know that the action was successful before moving to the next step in the automation.
We look okay on utilization for automations right now and will ask the team their thoughts on adding more re-fetches to the other automations. What is irksome about this is the issue type update is what is triggering Step 2 but it is failing on the conditions validating the change.
I had previously tried this as one automation with a refetch between actions/conditions and found that the refetch was still showing original values and the conditions were failing. That is why I separated the automations hoping that the action of the first automation will successfully trigger the second (it did!) and pass the necessary conditions (i didn't).
Really appreciate you iterating the speculation and providing more background. That gives me more insight into how this works under the hood.
Have you (or your colleagues) contacted Atlassian Support at all about the "Jira was slow to respond..." message? Since you've seen it a bunch of times, it might be worth opening a ticket.
Did you try using Re-fetch in strategic spots in your previous "all in one" rule? If not, it might be worth combining these two rules back into one and trying that. At the very least, it will be less impactful to usage limits.
If you contact Atlassian Support, having both efforts (single-rule and separate-rules) in your instance for them to see and replicate will likely save time (as they will almost certainly suggest trying both approaches).
This automation rule looks like it should run fine as-is (with the refetch).
"Jira was slow to respond" is often an indication of a very active instance or an instance experiencing some systemic issue. Support is the way to go here. From the conversation it appears you've done that and are awaiting more info form them. 👍
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events