Possibility to "integrate" 2 JSM instances using emails

Danilo Simic

Hello everyone,

 

We have the following:

• We have our own JSM cloud
• One of our service providers also uses JSM cloud
• This service provider opens a request in their JSM from time to time after collecting some analytics data (the request has well over 15 fields with different information)
• We are notified about this request because we are added as participants in the request
• Once we see that the request has been created, we manually create a request with similar information in our JSM instance to the corresponding client (the client wants to have visibility of this information so that is why we open another request in out system)

 

As you might image, the problem is the constant manual updates. At the moment this is not much but we expect other clients to request this visibility as well. Please keep in mind that updates can go both ways (so if our client provides some information, we pass that on to our service provider).

 

What would be the easiest way to automate this process?

 

Our current idea is to try and use the emails that JSM sends as notifications when requests are created and updated in order to do something in the system (create a user with a unique email address just for this use case). The problem is that we can not find any useful information/documentation that would help us achieve this.

 

Any other suggestions on how to solve this are welcome. Please keep in mind that we would like to avoid hard integrations such as API, integration tools or plugins, of course, if you think there is a simple and easy solution that does use one of these methods please let us know.

Utkarsh Agarwal

Hi @Danilo Simic 

Integrating two Jira Service Management (JSM) instances in Jira Cloud can be accomplished by leveraging Jira's powerful Automation Rules feature. While the integration typically involves APIs, you can achieve the majority of the integration using automation alone, without needing to write custom scripts or handle API calls directly.

Here’s a step-by-step solution on how to set this up using Automation Rules:

1. Setup Automation in the First JSM Instance

First, we’ll create an automation rule in the first JSM instance (Instance A) that will trigger an action when an issue is created or updated.

Automation Rule Configuration:

• Trigger:

  • Issue Created or Issue Updated (depending on your needs). This will start the automation whenever an issue is created or modified in Instance A.

• Condition (optional, based on your use case):

  • You may want to filter issues based on specific criteria, such as issue type or specific fields (e.g., if the issue is of a certain priority or customer type).
  • Example: Issue type is 'Incident'.

• Action:

  • Use the "Send Web Request" action to interact with the second JSM instance’s API. In this case, you’ll use this to create a corresponding issue in Instance B.

    • Set the request method to POST (to create a new issue).

    • Set the URL to the Jira REST API endpoint of Instance B, e.g., <a href="https://your-instance-b.atlassian.net/rest/api/2/issue" target="_blank" rel="nofollow noopener noreferrer">https://your-instance-b.atlassian.net/rest/api/2/issue</a>.

    • Include the necessary headers for authentication (using an API token or OAuth):

      • Authorization: Bearer <API_TOKEN>
      • Content-Type: application/json

    • In the body of the request, map the data from Instance A to the corresponding fields in Instance B. For example:

      <span>{</span>
        <span>"fields"</span><span>:</span> <span>{</span>
          <span>"project"</span><span>:</span> <span>{</span>
            <span>"key"</span><span>:</span> <span>"PROJECT_B"</span>
          <span>}</span><span>,</span>
          <span>"summary"</span><span>:</span> <span>"{{issue.summary}}"</span><span>,</span>
          <span>"description"</span><span>:</span> <span>"{{issue.description}}"</span><span>,</span>
          <span>"issuetype"</span><span>:</span> <span>{</span>
            <span>"name"</span><span>:</span> <span>"{{issue.issuetype.name}}"</span>
          <span>}</span><span>,</span>
          <span>"priority"</span><span>:</span> <span>{</span>
            <span>"name"</span><span>:</span> <span>"{{issue.priority.name}}"</span>
          <span>}</span>
        <span>}</span>
      <span>}</span>
      

    • This will ensure that when an issue is created in Instance A, the relevant information is passed to Instance B to create a new issue there.

• Advanced Actions (optional):

  • You can also set additional actions, like adding comments or linking issues, once the issue is created in Instance B. Use the "Link Issues" action or the "Comment on Issue" action to notify users in Instance A that an issue was created in Instance B.

2. Setup Automation in the Second JSM Instance

You can set up a similar automation rule in Instance B to handle incoming requests or synchronize updates. For example, if an issue in Instance B needs to update or close an issue in Instance A, you can follow these steps:

• Trigger:
  • Set the trigger to Issue Created or Issue Updated (depending on your use case).
• Action:
  • Use the "Send Web Request" action again, but this time to update the corresponding issue in Instance A.
  • Use a PUT request to update the issue in Instance A’s JSM instance, based on the issue key or other identifiers shared between the two instances.

3. Handling Authentication and Security

For secure communication between the two instances:

• You can authenticate via API tokens (which can be created in your Atlassian account settings) and use them in the Authorization header (Authorization: Bearer <API_TOKEN>).
• Alternatively, OAuth can be used if your integration requires more complex authentication.

I hope this helps!

Kind Regards
Utkarsh