How to merge Atlassian software instances: a customer case

[#1]

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.

Getting started – the needs analysis

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.

What we learned

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.

Addressing the requirements

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):

• Projects – full configuration, SLAs, classifications, escalations, conditioned reply templates, mail flows, and integration (shared mailboxes/dedicated accounts), automation steps.
• Customer Portal – revision of the existing portal or creation of a new one, knowledge base integration.
• Knowledge base – defining content types, classification, permissions, integration with the customer portal to suggest solutions automatically.
• Chatbot – integration through API, best practices, and guidelines for automation, processes integration, and Confluence integration.

Prepare for these common challenges while gathering requirements:

• You might have to deal with a limited time frame when learning about the needs of two teams that provide separate services for large groups of users and customers. To create a highly functional Proof of Concept configuration, you should use the time of people effectively and always come prepared for your interviews with local administrators, team leaders, and managers. Once your post-work document is ready, administrators should be able to implement the configuration for production in a short time.
• Just like our client, you might decide to move between various hosting options (for example, from a Server instance to the Cloud). The new configuration needs to take into account all of the differences between the environments and their tools.
• Another challenge you might encounter is related to connecting a custom chatbot to Jira and Confluence. To make communication with customers effective, you need to include the assumptions of how it should work.

Identify the problems

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:

1. Lack of information about who is working on what, what is the status and progress of the task.
2. Too few issues resolved by the first line support.
3. Problem with knowledge sharing between support lines.
4. Requests reported via the communicator take too much time of the support team and don’t create and keep a shareable history.
5. Tickets reported by email are not identified automatically, and there are too many of them.
6. The ticket system (Jira Service Desk) should be available without a VPN.
7. Incident management, Problem management, and Change management were not optimally integrated, and additional manual work was required to make these processes work together.
8. Customers ignore most of the approvals.

Our solution

Jira Service Desk

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:

• sending a message via the Customer Portal provided in Jira Service Desk,
• sending an email,
• contacting an Agent through the company’s smart chatbot solution connected to the knowledge base and Jira Service Desk.

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.

Jira Software

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.

Building workflows

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.

Incident MANAGEMENT

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:

• send an automated comment to the Customer on behalf of the Agent (who was automatically assigned to the case) as the Agent started working on an issue,
• link different but related issues automatically,
• based on the previous steps of the Agent, decide whether the present workflow transition should take action or not,
• create new related issues that are preconditioned and proceeded in a certain way on the workflow transition,
• escalate issues easily,
• assign issues automatically to certain Agents (even related ones),
• make it visible on particular Support Level issues queue,
• send it to automatically (or manually) selected Approver or Approvers.

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).

CHANGE MANAGEMENT

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

SLA and automation

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.

Making the platform searchable

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.

Knowledge base

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.

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 recommend using standard Jira, Jira Service Desk, and Confluence REST APIs.
• Creating a solution incrementally, with minimum value added in each sprint, is a good idea too.
• Make sure that the first interactions use the existing customer request groups and types in the process of classification. The product should then present an article from the Knowledge Base as a fixed link.
• Limit the number of clicks and interactions required to get content. That’s how your chatbot will bring value to customers and replace the Customer Portal.
• Consider whether the chatbot should ask questions and collect information. Try to identify the problem from the general to detailed (or vice versa).

Final tips for merging two or more Jira instances

• Build the awareness of the potential benefits of using Jira Service Desk by creating educational materials for your customers.
• Limit the number of users with administrator privileges. Any changes to the existing environment need to be well-thought-out.
• Have a test environment where you can verify the impact of a change in the entire application. This is especially important for instances hosted on Cloud, where backup files aren’t stored on the Atlassian server for a long time.
• Update the information about the current status of work in the selected tasks in Jira on a regular basis. This will have a huge impact on the reliability of the generated reports.
• Make sure that each space in Confluence has its owner who will be responsible for the level of privileges and content stored there.
• Use Jira’s extensive notification options to send reminders of task statuses.
• Visualize selected process areas in queues and dashboards in Jira Service Desk.

We hope that this detailed step-by-step guide helps your organization in merging two or more Atlassian software instances.

[Taranjeet Singh]

nice article to share  your learning & experience!