Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Dealing with non-ticket issues that come into Jira Service Desk via email

As anyone using Jira Service Desk will I'm sure have experienced, if you have an "open" email address that anyone can email you get a certain amount of spam and other non-ticket stuff (I'm going to refer to tickets here, rather than issues, but I'm talking about tickets that exist in Jira as issues).  These tickets then have to be closed off.  In our case we transition them to Cancelled with a Resolution status of "Not a Ticket".

The problem with this is that over time you get a lot of these and they make it harder to find stuff when searching.  I've been mulling over the best solution to this and this is my idea, would like to see what others think:

1. Create another project as a clone of my main service desk project and call it something like "Ticket Archive"

2. Set the permissions of Ticket Archive so that most users can't view it (so the contents don't show up in search results).

3. Periodically use the Bulk Edit feature to move the "not a ticket" issues from the main service desk project to Ticket Archive

The main downside to this is that changes to the structure of the main service desk project would need to be replicated in the Ticket Archive project (new fields etc) to ensure that the issues could continue to be successfully moved over.

Does anyone have any further thoughts on this as a solution, a better solution, or other potential issues with this approach?



1 comment

Kat Marketplace Partner Sep 03, 2018

We delete tickets that have been created by mailing lists etc. We do not have any need to know how many tickets can in that took less than a minute to delete.

Thanks Kat that's not an option for us because we need a complete audit trail, and Jira removes the emails from the email inbox so we rely on keeping the issues as the record of when and what was emailed in to us.

We remove the reporter adress not to confirm to the spammer/phisher/attacker its validity or feed the internet with unneccessary notifications.

Then we move the issue created to the IT Depts Jira-project for analysis or updating the spamfilters.

Thanks Jim.  So are you moving the issues one by one or doing it a bulk process?  Or do you have some kind of clever workflow set-up to copy and delete?

Sorry @James H. no bulk process.

But our spam-workload in Jira is limited. We had a peak recently and it was no more than 5 spam messages a day passing the filters all the way to Jira.

What is stopped by Exchange Online by Microsoft though, before entering our inboxes is not known to me.


Log in or Sign up to comment
Community showcase
Published in Jira Service Management

Coming Soon: Insight Changing to Assets

The 2020 acquisition of Mindville added powerful asset and configuration management capabilities to Jira Service Management in the form of Insight. Following the completion of that integration, custo...

458 views 3 13
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you