Jira Service Desk Email Flood: Jira Vendor and Jira Client

[barronkid]

Scenario: 

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 support@vendor.com 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 support@vendor.com user when the item is escalated. 
3. The vendor receives the notification from our JIRA system's email address (support@client.com), 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 support@vendor.com 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 support@vendor.com to support@client.com.
3. My JIRA scrapes support@client.com, 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, support@vendor.com.
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.

[Hernan Halabi _Elite IT Consulting Group_]

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