We have an automation rule which triggers on issue creation. When issues are created from the Outlook add-in, the issue is evaluated and sometimes the issue qualifies and sometimes it doesn't (even when it should).
The rule should should be qualifying the issues from Outlook add-in every time based on the customer request type value we set (which are auto-suggested when setting up the rule, so we know it's not a spelling error).
Images below show example of problem: rule shows customer request type is one of Report Request but issue did not qualify even though the issue's customer request type is Report Request.
I think this may have to do with how the Outlook add-on creates issue.
Maybe it creates an issue then afterwards update it to set specific service management fields like customer request type.
If that is the case, since the automation rules are queued and run "async", if not configured otherwise, you may encouter an operation orchestration problem.
Sometimes the rule runs after the outlook add-on as completed editing the service management fields, sometimes not.
Again, this is theoritical and a guess based on my programming experience. You can try to add a transitory status at the beginning of your workflow, add a rule on Create that transition the ticket from the new status to the next one, and trigger your actual rule on this transition. If my guess is correct, it should fix your problem.
Thanks Pier-Olivier - that was my thought as well regarding updates *after* the issue creation, but the screenshot I provided shows all the issue history after the issue failed to qualify (just the single line where the issue is created).
Talking to Jira support, they say to re-fetch the issue history before the condition, but that seems really heavy on automation for something that *should* work. (The re-fetch can only be added before the first condition, so it would trigger on every issue created.)
Similarly, adding in any additional transitions creates the same load on automation rules when there's literally no other activity in the history of the issue that would account for the rule not triggering. It's odd.