Flag some incoming emails as "issue creation not needed"

[Michael Woffenden]

Our company has standardized on support@ourdomain.com as the sole means of email communication with customer contacts.  This has both advantages and disadvantages.

Advantages

1. Replies to issues automatically create comments on the associated Jira issue.
2. Incoming emails that are not associated with an existing issues create new issues.

Disadvantages

• We also use support@ourdomain.com to email a lot of communications to customer contacts. 
• In this case, incoming replies create new issues, however, many issues must be closed/deleted.  For example "thank you" and other "polite" emails all create new issues.  This is an annoyance, to some extent, to our customer contacts.  It's also an annoyance to us, since we have to deal with the extra noise and work of deleting those "non-issues".

Needed Solution

• We need some way to allow auto-creation of issues but at the same time "flag" some as "issue creation not needed" so that JSM will not auto create an issue for selected incoming emails.

Does anyone have an idea/solution to offer here?

[Mark Segall]

Hi @Michael Woffenden 

Unfortunately there is no simple solution to this.  Even if you had business logic to automatically handle the "noisy" responses, the damage is done as the issue gets created and associated notification rules will trigger.

I would recommend that for your generic messaging, you use a different reply-to address that goes to whatever mechanism you want for tracking those types of responses.  This way support@yourdomain will serve as ticket intake, and responses to general emails will be handled as desired.

[Michael Woffenden]

@Mark SegallAgree there's no simple solution, but we'll take any solution that gets the job done.

Your idea occurred to me, but it will not work for us.

We have a hard and fast rule that one and only one email address will be used for customer support.  As soon as we deviate from that, the whole thing breaks down.

So we will keep looking for a solution.  Where there's a will, there's a way!

My current thinking is some sort of email pre-processor logic.

[Mark Segall]

Another option is to disable the ability to generate requests via email and force your customers to raise requests via the portal.

[Michael Woffenden]

Great idea but still no go, we want that option available for those who refuse to use the customer portal.

At this point I have these thoughts:

1. Automation
2. Find a third party addon
3. Code an email inbox pre-processor that will handle emails before they get to Jira.  The pre-processor will figure out which emails to allow to proceed to Jira's email puller.

[Mark Segall]

If you're going to go the route of automation, I would consider a staging project with all notifications turned off that serves as the entry point for all requests and responses.  Then you could go this route:

Automation #1: Legitimate requests

Leverage a manually triggered rule that your agents can execute to spawn a new, linked request to the project they actively work in and mark the original as Resolved.  This would solve the issue of annoying your customers.

Caveat to this approach - Attachments cannot be copied over to the spawned issue so the experience will be less than desirable.  Agents would need to either manually download/re-upload the original attachment to the spawned issue or link to the original issue to gain access.

Automation #2: Illegitimate requests

Set up a scheduled rule that cleans up any issues that were not linked after n days.  This automatically clears out the noise.

[Michael Woffenden]

The staging project idea is interesting.  Two thoughts:

1. I'd like to automate the initial filter (instead of a manual trigger) if at all possible.
2. Instead if spawning a linked issue, wouldn't the workflow be simplified by just moving legitimate requests to the active project?

[Mark Segall]

Hi @Michael Woffenden 

1. If you have business logic that you can apply to the incoming issues, yes that would definitely be the ideal approach vs a manual trigger.  However, email is so dynamic that I would imagine it being very difficult (if not impossible) to establish consistent conditional logic to satisfy such a rule.
2. Unfortunately, Automation doesn't support moving an issue to another project otherwise yes, I'd absolutely recommend that approach.