Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Jira Service Desk Email Flood: Jira Vendor and Jira Client


  1. My users raise support requests in a JIRA Service Desk (server-based, if that matters) instance that I manage.
  2. Where appropriate, I need to escalate some of these issues to my vendor/provider.  I created their email as a 'service desk agent'-type user in my system and built a workflow transition called "Escalate to Vendor" along with an automation that assigns the issue to this user when the item is escalated. 
  3. The vendor receives the notification from our JIRA system's email address (, almost if I'd emailed it from a functional account.  Yes, I modified the email notification to make sure it would include the key details and comments.  Yes, I'd prefer they click the link in our notification to view and work with the issue, but they, understandably, prefer to receive a simple email and work with the issue directly in their own system.

Here's the problem ... 

  1. The vendor's inbox is scraped by their own JIRA Service Desk instance, which creates an issue in their system.  
  2. The creation of this issue in the vendor's JIRA generates a notification, which is sent by email from to
  3. My JIRA scrapes, and processes the incoming mail as a new support request.  
  4. My JIRA finishes with the incoming mail by sending a notification to the sender, whose email is, yep,
  5. Vendor's JIRA creates a new issue in their system and generates a confirming notification back to my system, and ...
  6. again ....
  7. and again ...
  8. and so forth.

What suggestions do you have for a configuration or automation or something (anything) that would meet all of the following requirements:

  1. Each party can work in their respective JIRA system.
  2. Allow each system to tell the difference between substantive commentary, and send appropriate notification emails that will be received by the other as comments in their JIRA system. 
  3. NOT have either of the two systems inundate the another in a way that generates duplicates or, worst case scenario, produces an endless loop of new notification-based issues.

1 answer

Hello @barronkid  I dealt with scenarios like that in the past and you can find in the marketplace apps that can help you sync issues between two instances. That would be the pretty solution.

I recall that those weren't an option for some of our customers so in order to avoid the loops we did something like the following.

Disable the new ticket notification and create an automation that does exactly the same for all but the other Jira e-mail. That way the Jira services don't notify each other that they got the email.

I believe that we ended updating the summary as well to contain both tickets IDs so any comment would go to one or another ticket without creating a new one.

I hope I'm not forgetting any other change we did. Let me know how it goes

Suggest an answer

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

Why upgrade to Jira Service Management Premium?

We often have questions from folks using Jira Service Management about the benefits to using Premium. Check out this video to learn how you can unlock even more value in our Premium plan.  &nb...

227 views 1 6
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