Eliminate Email Component Generated From Re-fetch Automation Step

[Todd]

We are using the Re-Fetch automation, and have to use that step three times to complete the calculation field in a report.  the Re-Fetch option has an email component included within the automation.

Is there a way to remove or suppress the email's that are generated from this automation step. 

[Bill Sheboy]

Hi @Todd 

Short answer: maybe.

For a question like this, please post images of your complete automation rule and the audit log details showing the execution.  That will provide context for the community to offer suggestions.  Thanks!

Without seeing your rule, I suspect you need to perform/store the results of any calculations (perhaps with the Created Variable action) and then make all the updates at once prior to a single Re-fetch action.  Again, no knowing if that will help without seeing your rule.

Kind regards,
Bill

[Jordyn K_ Lee]

Hi @Bill Sheboy , I'm working with Todd on this. 

The re-fetch component in the automation rules is really nice for interaction between fields in the given ticket to reduce load time. However, where as in every other component option email can be activated/deactivated, this one does not make this an option. 

The automation runs so slow it is not worth having it at all if I can't use this re-fetch option. But I can't have people getting emailed for every single use of this rule. 

[Jordyn K_ Lee]

[Bill Sheboy]

Hi @Jordyn K_ Lee 

Just to confirm...are the email notifications being sent due to the field edits or are they being sent by something happening later in the rule?  You are not showing the complete rule so I am unable to determine that.

Also, seeing the complete rule may explain the slowness you describe.  A re-fetch seems to take one or more seconds (in my experience).  It is possible this rule is triggering itself, as the timing of the edits/re-fetches could cause that.  One way to prevent that processing is to add a user condition immediately after the trigger:

• user: User who triggered the event
• check to perform: is not
• criteria: Automation for Jira

This will halt the rule if it triggered from a rule initiated edit.

Kind regards,
Bill

[Jordyn K_ Lee]

the emails are sent when any of the 4 fields are changed from their default status of "0". 

I don't think I want to halt the rule in fear of it canceling what the re-fetch needs to accomplish. Or worse, not complete the calculation in the fields. 

I have already combed through the different steps throughout the rule to ensure no part has "email" checked on it. the re-fetch doesn't give any such option. 

[Bill Sheboy]

Hi Jordyn,

Re-fetch does not send an email; it only reloads the trigger issues data for the rule's usage.  The thing you underlined in your image is an example rule showing how re-fetch can help prevent problems.

I was instead asking if you have a Send Email action in your rule, or just the edits are sending notifications, such as to watchers.

Regarding the condition I suggest to halt the rule: that will only stop any downstream executions of the rule when it triggers itself.  It will not halt the originally running rule, as the edit came from a person, correct?

Thanks,
Bill

[Jordyn K_ Lee]

my apologies for the delayed response @Bill Sheboy . I underlined that as that is the only space I see where it says an email will be sent. 

I have reviewed every step and made sure that the normal checkbox to send emails is unchecked. 

I don't normally require the re-fetch feature, so with that description, that is the only reason I can think an email is going to the assignee of the ticket every single time the calculation is run. 

[Bill Sheboy]

Hi @Jordyn K_ Lee 

Have you checked if the assignees are also watching the issues?  That may explain why they are getting the emails for all of the changes.