This article was written by Piotr Mazij - an Atlassian Expert and Trainer at Deviniti.
Do you know how many instances teams use at your company? You can benefit a lot from integrating them by implementing a unified stream of activity, connecting your reporting panels, and facilitating links between projects. However, integrating multiple instances comes with its share of challenges. If you’re wondering how to carry out the process of linking two Jiras, this article is for you. In what follows, we show you how to connect a couple of instances step-by-step on the basis of a real implementation we completed for one of our clients, a leader in the field of Intelligent Automation and Robotic Process Automation.
Our client asked us to first carry out a workshop to develop a solution for merging two Jira instances used by two separate teams. This is the best first step to this type of project: have your team analyze the processes, and create a Proof of Concept of the configuration that can be easily managed and reused in other projects. The final result should then go to all of the teams/departments using these instances. Make sure to include a set of recommendations for further development, including applications, infrastructure, possible improvements, best practices, and configuration rules.
During our initial analysis, we learned that our client used many different tools to support project management and handling daily tasks. Information Technology and Managed Services departments provide support for internal and external customers using Jira Service Desk. One of them hosts it on a local server, while the other uses the Cloud version. The process entry points are Customer Portals, emails, and private messages sent to the Agents. Two of these entry points require extra work to gather more information and classify tickets – a problem our client was aware of. Since removing these points was impossible, our client decided to implement a chatbot and move some amount of classification work away from agents. Both teams use the same standard ITIL processes (Incident Management, Problem Management, and Change Management) – with one exception, as the Service Request is used only by the IT team. However, they are all separated and implemented primarily as built-in Jira workflows and SLAs. Some flaws in the project configuration were causing categorization and reporting problems. The client also wanted to rebuild the Customer Portals that were built using the standard Jira built-in scheme that didn’t match the company’s unique requirements. They also used Confluence as a knowledge base, but the covered use cases are limited.
If you’re working on a similar project, make sure that your approach addresses the requirements for the following elements that you’re looking to integrate (note: you might not need each and every one of them):
Both departments of our client indicated some problems they encountered during their work at various stages.
For example, the Managed Services team pointed to the following problems:
Once we identified the technical and process requirements of the two teams, we were ready to start working on a solution.
Here’s a visualization:
References: red lines – request creation channels, blue lines – links between created requests, green lines – use of the knowledge base
The image above represents our solution. A customer (internal or external) can search for an answer in the provided Knowledge Base (hosted in Confluence) and/or raise a ticket by:
The main goal of this project was to have both teams using one Jira Service Desk. To accomplish that, we discussed the pros and cons of using the Cloud and Server versions of Jira. The main reason behind that switch was avoiding the use of a VPN. Since not all the available extensions are available for Cloud (even if they’re number is growing), we had to verify whether the key requirements would be met. Finally, we decided to migrate from Server to the Cloud version of Jira.
To prevent our team from interfering with the current projects, we created two completely new projects. These projects didn’t share the configuration with the ones already existing in the system. We used them only as templates, with the option of reusing them for the final production purpose. Thanks to this, our client could make improvements and migrate to the new solution at the most convenient time. This was a smart move also from the perspective of testing the connection and improvement of the custom chatbot and the client’s knowledge base.
We decided not to create a workflow matching the requirements 1-to-1. Since the process allowed it, we could iterate workflows wherever applicable. That’s how we were able to make it much simpler for the users.
This is the workflow we implemented for the purpose of Incident Management. It includes a lot of actions hidden in transitions.
From the technical point of view, we used many of the functionalities available in Jira Misc Workflow Extensions for Jira Cloud. These allowed us to:
In our client’s case and the company’s particular requirements, we blocked the Assign To Jira permission built-in functionality. Instead, we built a looped workflow transition that is easy to restrict, if needed. It also allows copying the Assignee value to technical fields that help to combine the work on issues related to the company processes (with the app functionality).
This workflow was implemented for the Change Management process. It allows skipping a part of the approval path if the issue resulted from a previous incident investigation
We configured the SLA clocks to start or stop under particular workflow transitions – and only for certain service request types. Moreover, some actions (such as auto-close or auto-reopen ticket) needed to be automated with the help of the built-in Automation functionalities. This was to be done by the client’s administrators once they ensured that the process doesn’t interfere with the testing of the new configuration.
To make the data easily searchable for queues and reporting, we created a technical field invisible to users or customers only where needed. We also aimed to reuse fields and data whenever possible. For example, an automatically created Knowledge base issue includes a Description field, which contains a combination of data from three fields in the original ticket.
The problem with our client’s knowledge base was that only a small part of the knowledge was available there – and to very few people. We decided to change that. Our team showed the client how to describe content to make it easier to find. We also presented nuances of the Confluence and Jira constructions that allow us to separate the content available to internal users and end customers. This was essential in the integration of the knowledge base with the chatbot.
The chatbot is a product developed by our client for its customers and uses certain features provided by Microsoft Azure.
Here are a few tips for teams looking to create a chatbot that integrates with their Jira instance:
We hope that this detailed step-by-step guide helps your organization in merging two or more Atlassian software instances.