Create Issue automation trigger working AFTER email notification

[Julian]

Hi

I have create an automation trigger to add the contents of a customer field to the Summary field, so that it appears in the email notification Subject field.

i.e. I want the subject modded to show customer field + Summary field.

This works, but the email notification is seemingly sent BEFORE the automation rule is triggered, as it arrives with the plain Summary field in the subject, but the issue on the queue clearly shows that the trigger worked.

The odd thing is that if I create an issue in my portal myself, it works ok with the email having the modded Subject - although the initial just-created issue screen still shows the unmodded Summary field. Anyone else, it never works at all.

How do I get the automation to reliably trigger before the email is sent?

Thanks in advance.

[Yvan Martin · Accepted solution]

Hi @Julian

Developer from Automation here.

For a bit of background information Automation works off events being fired from Jira, so
in the case of your edit the event will be submitting around the time the email notification would have been sent out of Jira/JSD depending on your project. It's also worth mentioning Rules are also executed in an asynchronous manner, so although they should complete without a long delay some delay is expected due to the nature of executions happening from different events at the same time.  

There isn't too much we can do to support your use-case while emails are sent out as a seperate process unfortunately. You could use the send email action to send one through Automation itself would can get the updated field. But then you'd either get 2 emails, you might be able to configure your  regular notification scheme to stop the Jira ones being sent but that may also impact your other types of rule edits that may not fire off a rule.

If you have any other questions, feel free to get in contact with Atlassian support https://support.atlassian.com/.

Cheers.

[Julian]

Hi Yvan 

Thanks for clarification of the mechanics of how, or more importantly when, rules are triggered.

I'll at least be able to stop my attempts to solve this without wasting more time on it.

I do see the trigger working "on time" in some cases, which fits with what you describe. I'm going to leave it in place as it still helps, and ultimately we wish to stop relying upon the emails anyway.

Thanks for taking the time to reply.

Julian

[Stefan Salzl]

Hi @Julian and welcome to the community,

I´m afraid I didn´t fully understand the whole use case from beginning to end. Could you provide a step by step description in a functional way (more from a flow perspective not in a technical or system way, just as you would describe somebody that is not familiar with jira). The given - when - then notation is very useful in that case.

Also for better understanding and analyzing the problem/use case:
Please add a screenshot of the current automation rule and all related increments (like in this case issues, sent emails,...)

Thanks in advance.

Best
Stefan

[Julian]

Hi Stefan

Thanks for your reply. I have included a snip of the rule below, and as you'll see it is pretty simple.

Objective: amend Summary field to be custom field + " : " + Summary.

This is for the benefit of agent users receiving email notification of the new issue being created. The custom field contains a customer code, so adding it makes it obvious from the email Subject field (= the Summary field) alone, who should react first to the new issue.

This will trigger for every new issue created. 

The particular custom field is added into the contents of the standard Summary field.

Standard "new issue created" email notification is sent.

The problem is that although all saved info is correct when we look at new issues in Jira, the new-issue-created email notifications show the original, unmodified Summary field in the Subject.

[Stefan Salzl]

Is this issue created in jira service desk? When is the email sent? is this also done by the automation rule? How is the rule continuing and what is the "refetch data" for? (--> I´m asking as the refetch would fetch data from the issue as it was at the point of the trigger). Could you try to run the rule without the refetch?

Best
Stefan

[Julian]

Hi

Yes, a service desk.

The email is not sent as part of the automation, it's via standard Notifications configuration (Event: Issue Created -> to Service Desk Team).

I was clutching at straws with the refetch, trying to solve the issue. I recognise now that it is pointless as it behaves the same with or without. I will remove it.

Thanks for giving this consideration Stefan.

[Stefan Salzl]

okay. Are the issues created via form? 

[Julian]

Yes they are.

[Stefan Salzl]

guess we are very close now :)

I remember a question here a few weeks ago where this was exactly the case that a processing of a form action took longer than the trigger of the automation rule. I will go through my recent posts as I was part of that question/discussion and will let you know what I found.

Best
Stefan

[Julian]

oh, thanks!

I did try searching first but could not see anything I thought looked relevant.

J

[Stefan Salzl]

Please see the very first answer. The reporter himself added the answer after getting in contact with Atlassian support.

https://community.atlassian.com/t5/Automation-questions/How-to-handle-multiple-actions-from-different-field-checks/qaq-p/1949361#M3381

Hope this is solving the problem.

Best
Stefan

[Julian]

So he uses a makeshift "pause" to slow it down in his situation. Not an ideal solution - making extra refresh calls is surely a drain on the system.

But in any case, the last thing I need is an increased delay. I think the root cause is the automation not happening quick enough - the complete opposite of that guy's situation, unless I am misinterpreting it?

In my case the Issue Created email is sent before the automation has had a chance to run. Slowing down the rule would only make this worse.

Please correct me if I am reading this wrong though!

Julian

[Stefan Salzl]

Your guess makes sense to me. Still I´m not quite sure which event is "overtaken" by the other one (means: from a technical perspective --> when exactly is the create issue "fired" within jira? maybe the notification itself fires too early and would also be done later if automation rule is postponed with a makeshift "pause")

I´m not into that deep technically in Jira. Did you give it a shot? (even though I am with you: imho this is still a dirty fix 🙈).

Otherwise I would suggest to reach out to Atlassian support with this case 🤷‍♂️ 

Hoping the best 🙌

Best
Stefan

[Bill Sheboy]

Hi @Julian 

First thing, I am not using Jira Service Desk.  That out of the way...

With two asynchronous things happening like this for Jira Cloud, I hypothesize there is no amount of Re-fetch actions that will guarantee this to work consistently.  My recommendations if you need this behavior are:

• check if forms have any workflow processing which allow making the field change before it is saved as "new"
• disable default notification and send emails from this rule
• contact support to learn what other alternatives they suggest

Kind regards,
Bill

[Julian]

Thanks for the replies & suggestions.

It's an interesting one. I'm still feeling my way here, as it's early days with Jira for us and any assistance is very much appreciated.

I may eventually have to make enquiries with Support on this one, but will persevere in the mean time.

Julian