Best practices to filter spam(unsolicited) email requests to JSM

[Kostiantyn Nikolaiev]

My company just started to use JSM and main goal for the first iteration is to start collecting and tickets which our clients send to our support email.

Our obvious setup includes email channel as a main source of new tickets and anyone can create a ticket by sending an email to support address.

We also have Slack integration in place, which is a really convenient way to keep everyone up-to-date and allows us to communicate internally about new requests very swiftly.

The issue is, that we have tons of automated emails being sent to our support address each day. It generates huge amount of tickets and also makes Slack integration barely useful, since real action items are hidden under piles of duplicates and unnecessary tickets. Back then, we were using email filters in our inboxes to keep everything clean and I assumed that such kind of feature should be definitely present in JSM.

Best answer I've found so far was suggestion to setup automation and deleted repetitive tickets once they being created. Another option is to revoke access from users who create those tickets (send emails). In that case they supposed to be stoped from creating tickets via email. Unfortunately, it does not work:

1. To trigger automation, JSM has to wait till ticket is created -> ticket ID increments by 1 (and with our burn rate it is about 150-200 tickets per day) and we are getting hundreds of notifications to Slack which becomes meaningless

2. In current JSM instance (we use cloud) I cannot "Revoke access" to a reporter, as suggested in the answer above. I can only "Remove" user. In that way, nothing stops same email sender to create new tickets.

Question for the community. Am I missing some other best practices to filter unnecessary email-generated tickets? Options like:

1. Blacklist emails preventing new tickets creation.

2. Add new triggers for Automation which will happen before any ticket gets created.

3. Allow to create groups of clients with restricted access and not allowed to create tickets.

4. Ad to Spam contexts command in ticket details which will not allow to create similar tickets in Jira by same user.

Any hints are welcome, since this experience is really frustrating.

UPD: These options should help for known sources of recurring emails - 

[Carmen Nadeau]

Hi @Kostiantyn Nikolaiev 

We faced something similar in our server instance. We needed to link a specific email adress to a project/issuetype. The problem was that email adress contains lots of emails that should not became issues. 

What we did is that:

• We created another email adress, here we will name it ProjectNameJIRA@domain.com
• In the original email adress (here we will named it original@domain.com) we used rules to select the specifics emails and add in the rule a MOVED to (and not forward) the emails of our choices to ProjectNameJIRA@domain.com
• We added an incoming email server linked to ProjectNameJIRA@domain.com

The moved rule let us keep the email adress of the sender and thus let us identify him/her and the rest of the rules let us process the emails that needed to either become a new issue or to add a comment to an existing issue.

I hope this can help you !

Carmen

[Kostiantyn Nikolaiev]

Thank you! That's also an interesting case.

[Patrick Haley]

We did something to what @Carmen Nadeau suggested. Another thing we did was change the settings for our support@ email group to reject emails from external domains. We only use this for internal support so it wasn't an issue. We do use other support-related email groups for developer account notifications and whatnot, but these are not actioned in Jira.