Previously working automation now failing due to no request type match error

[Connor]

I have an automation that triggers when an issue in project DBO is assigned and performs actions against a linked issue in project RSM when that issue matches specific conditions. One of the conditions is the linked issue must be a specific customer request type. This automation has been working successfully for several months, most recently on May 28th. Last night though it failed with an error that there was no matching customer request type, and suggests to use the JQL auto suggestions to find the customer request type I'm looking for. On the rule condition if I "Validate query" it successfully returns results, and if I use the full JQL query shown in the audit log that also returns the correct linked issue. So why in the world did the automation fail last night?

This screenshot shows the details of the condition the automation failed on.

This screenshot shows the audit log for the last successful execution on 05/28/2024.

This screenshot shows the audit log for the failed execution on 06/05/2024.

This screenshot shows the correct results returned when using the JQL query outside of the automation.

Any help deciphering why this automation failed would be greatly appreciated.

[Connor · Accepted solution]

Hi @Trudy Claspill , @Leonard Hussey , and @Anne Saunders I have discovered the root cause of this problem. I am part of the EAP for request type restrictions, and at the beginning of May I set restrictions on several request types, one being the request type the JQL query couldn't find. There was one part of the documentation that I overlooked, which was:

If a user doesn’t have access to a request type, they won’t be able to search or raise that request.

I realized I had access to the request type, but I had not provided the "Automation for Jira" user access to the request type. After granting the automation user access to the request type, the automation was able to execute successfully. Also, if I removed my access and tried running the JQL query, it would return the same "no customer request type match" error that was logged in the automation rule audit log.

[Leonard Hussey]

Ah great. Will keep in mind for when it lands publicly. This would actually help us a lot. Thanks!

[Anne Saunders]

I have done that (not provisioned the automation user quite right) more times than it feels good to admit. Well done!

[Trudy Claspill]

Hello @Connor 

Is the RSM project Company Managed or Team Managed?

Do you have any (other) Team Managed Service Management projects on your instance?

I wonder if the automation may be getting confused if there is more than one request type by that name, and if one of them exists in a Team Managed project. Identically named fields where 1..n of the fields exists in Team Managed projects has disrupted automation rules in the past because it becomes unclear which field is intended to be referenced when there are multiple fields with the same name.

[Anne Saunders]

This is one of the reasons we don't use team managed projects by policy. It's just too easy for people to innocently gum up everyone else's works.

[Connor]

Hi Trudy, both projects are company managed, we don't use any team managed projects and have the ability to create them disabled.

[Leonard Hussey]

another idea: is this cloud by any chance?

we sporadically face the Atlassian gremlins. Usually around 00:00 GMT.

e.g. Some automations that depend on the group(s) to which a user belongs do not work and then some minutes after they work just fine. No changes at all.

We take it as if they pushed something live and there was some minor glitch during the push.

meh. just an idea!

[Connor]

Hi Leonard, this is cloud. I was wondering the same thing, but this automation triggered 8:23pm PDT, which I think converts to 423am GMT. I haven't yet had a chance to try and replicate the problem, but I'll post my results when I do.

[Leonard Hussey]

Hi Connor.

Dumb question: is the actual ticket that trigger the automation by the assignment action really linked to another ticket that fulfills your conditions?

I ask because, in my caffeine-less daze, I can only think that the JQL in your automation which returns 31 results is running without the added context of the source Issue which is added by default during the actual automation run as an extra AND condition. I mean: the ticket is checked to belong to the 31 ticket subset.

So: does it belong?

this is the only thing I can think of right now.

Regads,

Leo

[Leonard Hussey]

ah. my bad. I see the last screenshot more clearly now. The annotations threw me a curve ball. Sorry.

Then only if they were not linked at the time it run? I mean: assignment was first and linking after?

[Connor]

Hi Leonard, yes the linked issue does fulfill the conditions. The JQL query that returns 31 results doesn't include the "created by" link type which is directly part of the related issues condition. The JQL query shown within the audit log contains the full query used for the related issues condition, and that returns the correct linked issue.