Jira automation and Next Generation Mail Handlers
Last updated
Was this helpful?
Last updated
Was this helpful?
Jira’s built-in Automation feature is “a no-code rule builder that enables customers to build if-this-then-that-rules based on events in Jira.
Rules allow you to automate actions within your system based on criteria that you set. Automation rules are made up of three parts: that kick off the rule, that refine the rule, and that perform tasks in your site.”
But what happens when you leave comments or carry out other actions based on incoming or outgoing emails sent or received by Email This Issue?
When the action is carried out by a customer, an agent or another licensed user, automations run as intended.
If a public comment would be added by an external sender (someone who is not registered in Jira) or a customer that the issue is not shared with, the comment is added by the default reporter of our app, as the senders would not be permitted to add public comments to issues by default.
This could be problematic if you have an SLA that depends on an agent’s public comment (such as the First Response Time SLA). In the above case, the commenter is an agent, the comment is a public one, yet the SLA should not be affected as it isn’t an agent on the issue leaving the public comment, but a technical user. In this case, one has to choose between their SLAs being fired or their automation running smoothly. If you want to keep your SLA intact, the automation will not work due to a Jira API limitation.
The Default Reporter Comment Event setting provides you with a choice to configure how to handle such cases that would otherwise break your SLAs or stop automations from running. There are three available settings, out of which only one triggers automations properly in cases like this one. Read more .
The No event and Email This Issue Event settings stop automations from running, while the Service management Event option allows for automations to be triggered as they normally would.
However, in the case of the first two options, we must evaluate the situation and see if we can create an action within the handler that is similar to the automation that is being stopped from being triggered.
The following actions are available in both automations and the next-gen handler:
· Add comment
· Alert user
· Edit request type
· Edit issue
The Auto-approve, Webhook and Send emails options are not supported.
In case you would to leave a pubic comment when the email’s sender is external and you want both your SLAs to remain intact AND your automations to run, configure the following in your handler:
This will check if the sender is external or is a user without permissions, it will leave a public comment, then it will run whatever action you would have in your automation that is available in Email This Issue. This could be running a workflow transition, setting issue field values (such as request type or other values that would be otherwise covered by the „edit issue” automation - in this case the Summary) or adding another comment.
The comment action config in the first IF branch is the following:
If the sender is a Customer or an Agent, the Default Reporter Comment Event in the comment action can be set to any of the three options as it will not be triggered (remember the sender is a customer or an agent) and the automation will run anyway, SLAs will not break.
When there is an Execute workflow transition action in the handler as well as one that depends on an automation, one might wonder which transition runs first.
If in the handler the transition is higher up on the list of actions than the comment, the automations run smoothly.
If in the handler the Add comment action is higher up on the list of actions than the execute workflow transition action, then our comment will asynchronously trigger the automation and this can cause problems.
Because of this, we recommend as a best practice that you place any transition actions in your handler above the comment adding actions if possible.
