As teams and companies grow bigger and new work management systems are introduced to facilitate collaboration, the need to integrate data becomes more evident. For instance, you might be working in Jira Server or Datacenter and you decide to synchronize some data with another team using Jira Cloud. So in this article, we’ll show you how to securely integrate multiple Jira instances without having to leave your familiar environment.
You should meanwhile address all the possible risks that might occur if the integration is not set up properly. Risks that can lead to unnecessary repeated work and inaccurate or outdated data. That’s why the security of the connection is a high priority which is covered here.
Here’s what you’ll read in this thorough guide:
- Why do we Need a Secure Synchronization between Multiple Jira Instances
- Different Approaches to Syncing Multiple Jira Instances
- Choosing the Right Technology for Jira Integration
- How to Integrate Multiple Jira Instances in 5 Steps
Why do We Need a Secure Synchronization between Multiple Jira Instances?
Some Use Case Examples
One example is Companies getting their product feedback from customers and customers suggest enhancements and extra features. This information can be really valuable both to the company and to the customers themselves. This kind of interaction also builds a community with everyone contributing to the development of the product.
Implementing this is not easy though. There is a risk that too much information will be generated and managing it will become difficult for the company. On the other hand, customers may find their complaints are going unanswered.
A second example, when the business requirement is that companies will be involved in the co-creation of products and services with external parties. This could be a marketing agency working with a design company, for example. If these companies want to create campaigns for their customers, they need to share information and coordinate effectively.
A third example would be a product development company working with a quality control organization. In this case, the development team would work on a product, and the quality control team would validate releases, ensuring they complied with regulations, and met consumer standards. Both of these teams would need to track details. Much of this information would need to be shared, though not necessarily in the same format.
How integration leads to the most effective collaboration
In the above situations, the different groups need to exchange information. This is transactional in nature. So a structured approach is the most effective. That way, data can be shared quickly, regularly, and easily. A tool to do this can have a transformative effect on workflows. If data is transferred from one platform to another automatically, then there is no need for human involvement.
This means all data will always be shared automatically, rather than just what people remember to manually share. A tool can also ensure data is modified according to the needs of each group.
A Customer Case
We’re going to look at one specific use case here – when a customer makes a request. We need to ensure that our system handles these requests in the same way, and goes through the same steps each time.
The steps are Open > Accept > Root Cause > Provide Workaround > Resolve > Close
The steps highlighted in bold are those that product engineering needs to be involved in. So the customer and support team will handle the creation of the request and the associated information capture. The developers will then investigate the issue, look for the cause of the problem, and try to find a solution. Then it will be fixed and closed.
In immature products, there will be more issues and they are likely to be more urgent. As products develop over time, the issues are likely to become minor, though major problems may occasionally arise.
Not everyone needs to be involved at every stage, but the information flow needs to be managed to keep everyone working efficiently as well as keep everyone updated when changes relevant to them occur. So we need a process that translates customer requests into effective changes in the product. Engineers will be using their own issue tracking system and this needs to be integrated with that being used to track customer requests.
Some of the data entered by customers will be useful to the engineers, but not all of it. The internal discussion by the engineers needs to stay private, and much of the information they use internally will not be useful to anyone else.
For our discussion, we’ll talk about two teams (the customer service and the product engineering team) working on two different systems, Jira Cloud and Jira Server. These teams may or may not be in the same location, they may be in the same open-plan office, or distributed all over the globe.
Different Approaches to Syncing Multiple Jira Instances
There are several potential solutions to integrate the systems. Let’s consider some of the available approaches and look at the advantages and disadvantages of each.
Single Project Configuration In One Shared Jira Instance
- Either raise customer requests in the same environment used by the product engineers.
- Or have the engineers handle escalated issues in the context of the support environment (interacting directly with requests in the system).
The disadvantages are that the workflows are different by nature:
- Product engineers are not fully engaged in the support process and need to understand how support operates, as well as the language used when responding to customers.
- Support engineers are not fully engaged in the product development process and need to understand how product development operates.
- Customer requests are always unplanned work and need to be managed separately.
Two Configurations, One Jira Instance
- A service desk environment and a product environment fully separated in the same Jira insance.
- Systems for escalating issues between each one.
- Needs to exchange comments, attachments, statuses, and other information.
- Easy to route issues to the correct team.
Several security-related disadvantages:
- Customers need to raise issues on the instance means it needs to be exposed to the internet. Since the product development system is also on the internet, it could become exposed too.
- Configuration changes might create a security hole.
- The integration of back-end product development support tools becomes a problem as these are supposed to be internal only. This includes continuous integration, testing, and source code.
- There are two separate configurations, which both require maintenance.
Two Configurations, Two Synchronized Jira Instances
- Give each team their own instance. A public-facing instance hosts the service desk environment, and the product development team uses an internal, firewalled, instance.
- The public-facing instance can be on a company DMZ, adding additional security. Alternatively, it could be in the cloud.
The disadvantages of an on-premise, public-facing instance:
- Both instances need maintenance. This could include licensing and hardware, as well as work done on the systems.
- The separate systems need to be connected, so information can be exchanged between them.
Choosing the Right Technology for Setting Up a Jira Integration
To set up a connection from Jira Cloud to Server, we’re going to use a cross-company integration solution called Exalate. Exalate is designed to solve our problem and avoid the potential disadvantages of using multiple systems to store and share information.
Exalate was designed with specific criteria in mind. Firstly, when different systems are integrated it is critical that they maintain their autonomy.
Adjustments must be possible on each side separately without having to consult everyone. Teams need to be able to make changes, without affecting the configuration of the other side of the integration.
Autonomy also allows you to keep the information on your own systems private. You don’t necessarily want internal project discussion available to people on other teams, and certainly not clients.
Secondly, reliability is important when linking platforms. If changes or crashes at one part of the system affect the whole thing, then it increases the impact of problems. A well-designed system should be reliable enough to mitigate problems, not propagate them.
Flexibility is also a major concern. The integration needs to be adaptable, so future needs can be met. If this isn’t the case you may need to use a second solution that can meet the requirements and this is an inelegant solution. As your business grows and expands, your needs will change and your integration platform needs to meet the new challenges that emerge as a result.
As well as the benefits stemming from this core design philosophy, there are a number of other advantages to using Exalate. Its standard configuration is the same for both of the Jira environments, so it is easy to make sure both are working in the same way.
Exalate is quick and easy to set up. If everything goes smoothly, a basic configuration can be set up in less than an hour (assuming that the infrastructure and network allow for such a connection).
We can also replicate the process quickly for other platforms. The setup process below can easily be adapted to link other services. In addition to connecting Jira Cloud to Jira Server, we could connect Zendesk to Jira Server, ServiceNow to Jira Server, or ServiceNow to Github, and those are just a few examples.
There are several good reasons to use Exalate. Now we’ve picked a solution, let’s see how to implement it.
How to Integrate Multiple Jira Instances in 5 Steps
Now we’ll move on to showing you how to set up the collaboration using Exalate. We’ll walk you through installing Exalate on both Jira instances, followed by a look at how we can control what information is exchanged, and the conditions under which that happens.
One advantage of using Exalate is that its interface is largely the same across different platforms, so if you have it working on Jira, you can go through similar steps to connect it to other platforms. In our example, we have a service desk application running on Jira Cloud, and a scrum application on Jira server. We want to link the two so that customer requests can automatically go from the support team to the product development team. We then want the support system updated when production has dealt with the request.
The first step is to install Exalate on both versions of Jira, so let’s start with Jira Server.
Step 1: Install Exalate on Jira Server
To install Exalate on Jira server, first, find it in the Atlassian Marketplace for Jira. To access that, hover your mouse over the profile button in the top right of the screen and select “Atlassian Marketplace”.
Several versions of Exalate will appear. The one we want is “Exalate Jira Issue Sync & more”, which should be at the top.
Click the “Free Trial” button to continue. If you don’t have a license, you’ll be taken to “MyAtlassian” to get one. Click the blue “Get license” button on the pop-up that appears. You’ll need to log in with your email, and agree to the terms and conditions. Then you can click “Generate license” to continue.
When your license is generated, a pop-up will appear and you can click the “apply license” button to activate it. Back in Jira, you’ll get a pop-up to confirm activation. Click the “Get started” button, and we’re done.
There’s also a guide to working with Jira server in the documentation. Take a look here for more.
Step 2: Install Exalate on Jira Cloud
The process for installing Exalate on Jira Cloud is essentially the same. This time, to get to the Atlassian marketplace, go to the settings menu, and click “apps”.
Once again, type “Exalate” into the search box. Click on “Exalate Jira Issue Sync & more”. Then click the orange “Try it free” button. A popup will appear, giving you some details about the application. Click the blue “Start free trial” button to go ahead.
A small window briefly will appear while Jira installs Exalate, followed by a “Success” popup when it’s ready. From there you can click “Get started” to go to the Exalate screen. Next, we’ll initiate a connection between the two platforms.
If you need more help, read the documentation on installing Exalate on Jira Cloud.
Step 3: Connect Jira Cloud to Jira Server
Now that we’ve installed Exalate on both of our Jira instances, we need to set up a connection between them. To do this, we generate an invitation code in one platform and then copy it into the other. We can use either one to generate the code, but we’ll start in Jira Cloud.
If you’ve just finished the Jira Cloud installation, you might be looking at the below screen already.
If not, you can get to it by clicking “Apps” at the top of the screen, followed by “manage your apps”, and then “Connections” in the left-hand menu, under the “EXALATE” heading.
To start creating our connection, click the green “Initiate connection” button.
Next, we can choose whether our destination instance will be public, private, or local. In this case, we’re linking a private instance to a public one. Our scrum server is behind a firewall, and our colleague responsible for cybersecurity doesn’t allow us to open the firewall. The customer support system is public. Since we’re generating this invitation in the private Jira server, we pick the public, as we’re connecting to the other Jira instance.
This allows us to connect public and private systems while mitigating many of the security issues surrounding this.
If we were doing the connection in the other direction, we’d click private for this step, but for now, click “Public” and then the green next button.
On the next screen, you’ll need to enter the address of your other Jira instance.
After you enter the address, more fields will appear, allowing you to give a name to each end of the connection. Those will be used to generate the connection name.
You can also enter a description. This is useful for describing what exactly your connection will be used for. Don’t forget, others may need to use it and may wonder what it is. Giving it a well thought out description will also help you if you have multiple connections used for different things.
Fill in the fields, and click the “Next” button.
Next is a screen that allows you to customize the connection further. We’re going to look at this in more detail in the next steps, but for now, we can just accept the default.
On the “Choose sync rules template” screen, accept the default, “single project”, and click “next”.
Next, you can pick the local project to sync entities from the other end of the connection. That means new items sent over from the other Jira instance will appear in this instance, in the project we select. Pick from the available projects and click “Initiate”.
After a brief wait, our invitation code is generated. Click the “Copy invitation code” button to copy it to your clipboard. It’s a good idea to paste this code somewhere safe. Once you’ve done that, click “Done”.
You’ll be taken back to the connections screen, where you can see our connection with “pending” status. To activate it fully, we’ll need to go into our Jira server instance.
In Jira server, click the settings button and select “Add-ons”. You’ll see an Exalate section in the left-hand menu. Click “connections”.
This time, click the “Accept invitation” button. On the next screen, paste the code we just generated into the space provided and click the green “next” button.
Once again, on the sync rules template screen, leave the default “Single project” selected and click “next”. You’ll next need to pick the project to sync with on this Jira instance. Choose one and click “Confirm”.
We can now see our connection in the list of connections, with the details we entered earlier. Next, we’ll see how to set up our connection to do what we want.
Step 4: Configure your Connection to Determine What Information Gets Shared
Now our connection is in place we need to make sure the data we’re exchanging matches our needs. Exalate is smart enough to match fields with equivalents on other platforms. It will create a set of defaults that should be adequate for most purposes.
You might want to change how this is done, however. Perhaps you only want to share a few details. You might want some information on a private platform to be kept back from a public one. Comments by developers would be an example of this. You may also want to pipe data to different fields.
We’ll go through a quick example next, but for more information read our script helpers guide. That will explain how you can make the adjustments you need to control how data is exchanged.
Let’s look at our Jira Cloud instance now. On the connections screen, which you can reach via the left-hand menu, look at the connection we created earlier. If you forgot how to get there, click “Apps” then “manage your apps” on the top menu, followed by “connections” in the left hand Exalate menu.
Our connection should be there, with whatever name you gave it. If you hover the mouse over it, three icons will appear. Click the left one, “edit”. You’ll see a screen like the one below.
Click “Rules”. We’ll come back to the triggers in the next step. You’ll see a list of sync rules that control how data on each Jira instance maps to that on the other. We’re looking at Jira cloud, so the outgoing sync shows how data is matched when Jira Cloud items are sent to Jira server.
The incoming sync shows how data from Jira Server will be mapped when received by Jira Cloud. Since we’re using two Jira instances, the field names are identical, making it easy to match them. If you’re using a different platform, this won’t be the case and you should check more carefully, to make sure Exalate’s default settings match what you want.
All these rules can be customized. If you don’t want a particular field synced, remove it. If you want a field replaced with a fixed value, change the value to whatever you want.
For example, change:
issue.description = replica.description
Issue.description = ‘from support desk’
To replace the description with text saying this issue came from the support desk. There are also some sections grayed out and surrounded by /* and */. These are meant to provide you with some hints as to how the synchronization can be configured. You can remove the /* and */ to activate these sections if you need the described functionality.
The sync rules let you make sure each instance stores the information relevant to the team that uses it. Adjusting these rules is a powerful way to automate your work.
Step 5: Set up Automated Synchronization Triggers
Now we look at the synchronization triggers. In the previous step, we changed what data was exchanged and how it was mapped. Here we’re choosing the conditions for sending data to synchronize.
We’re still in Jira Cloud, so if you just completed the previous step, click the “triggers” item to get here. Otherwise, it’s Apps >> manage apps >> notifications, then hover over your connection and click “edit”. Click the “Create trigger” button to get started.
There are several fields. The selection box at the top allows us to choose which type of entity we’re working with. If we pick “issue”, these rules will apply to issues.
The next box is the key one. Here we have to enter the JQL code that defines when issues are sent. JQL stands for ‘Jira Query Language’ and can be used to select a subset of the issues maintained on this instance. This sounds challenging, but it isn’t too hard to add a simple trigger, and if you use more advanced code the system becomes even more powerful.
In the notes section, you can add anything you like. This is useful for explaining what the trigger does in simple language, and is especially useful if you have multiple triggers and need to quickly see what they do.
At the bottom is an “active” switch, which lets you turn your triggers on and off as required. Don’t forget to activate your triggers, or they won’t work.
Here’s how our trigger form looks when we’ve added the details. We’ve used assignee = “Kevin” to apply this filter to a specific team member’s issues. We’ve also added a brief description, and set the trigger to “active”.
When you’ve finished, click the “Add” button, and your trigger will be active. It will be visible on the trigger screen.
Now that we have set up the connection between the instances, let’s test it by creating an issue and seeing if it syncs correctly. In Jira server, we navigate to our project by clicking “Projects” in the top menu and then selecting the project you are using for the synchronization.
Then click the green “Create” button to create a new issue. Make the assigned user “Kevin” to match our trigger (or whatever username you have used). Enter whatever other details you need, then click the “Create” button on the form to create the issue.
Now, if you go over to the Jira server instance and look in the issues on the synced project there, you should see the issue appear. Well done, things are working! Here’s how it looks for us:
If you don’t see it, take a good look at the trigger conditions and make sure everything is active. You’ll also need to click the “Publish” button when making changes to ensure they are added to both platforms. We’ve given an example of how you can collaborate across platforms without having to compromise on security. Our system allows customers, service desk staff, and developers to share information without stepping on each other’s toes. Each of these groups gets a workflow tailored to them while playing a role in contributing to the product as a whole. Tools like Exalate can make this kind of task much easier. When you look for a software integration product, you need to check whether it meets your business needs and lets your teams integrate seamlessly.
- How to Set up a ServiceNow Jira Integration (The Comprehensive 2020 Guide)
- Jira to Jira Sync: How to Synchronize Multiple Jira Instances in 8 Steps
- How to Set up a Jira Azure DevOps Integration: The Comprehensive 2020Guide
- How to Set up a Jira Zednesk integration (The 2020 Step by Step Guide)
- Jira GitHub Integration (The Comprehensive 2020 Guide)
- How to Set up a Power BI Jira Integration (The Complete 2020 Guide)