Expand Jira beyond company borders
Jira is one of the favourite tools used for coordination and communication between team members. Sometimes this collaboration needs to reach beyond organisation's borders and, although there are couple of integration options available, every time you will have to address the concerns of your IT security officer. In this article I will discuss a use case from my work with one of the Demicon clients, where these concerns were successfully resolved.
Exalate for Jira
As you probably know, Jira basic functionality can be extended with plug-ins also known as Jira apps. Exalate by idalko is one of these apps, and its purpose is to enable bi-directional synchronization of data between two Jira applications even if one of them is behind a firewall with no traffic allowed from the outside. What I like about Exalate is that it can effectively address the concerns of the IT security team and still be useful for the data exchange.
Exalate has introduced a term: private and public Jira instance. This means that a server behind a firewall, which is not accessible from the Internet is called ‘private’ and the one which is accessible is called ‘public’. It may seem counterintuitive at first.
How can you synchronize data when a server on one side cannot send data to the server behind a firewall on the other side?
I thought so too. However, Exalate is clever enough to synchronize data on both sides (both servers) even if only one can send and receive data. You can read more about this functionality here: https://docs.idalko.com/exalate/display/ED/Sync+Private+Jira+Server+to+Cloud
Practical Use case
How to Collaborate with an external services supplier
Large brewery. Agents managing tickets in Jira Service Desk receive daily hundreds of IT service requests from within the entire company. Some of these requests are resolved internally by the IT department team members. Other requests need to be sent to an External Services company, where some IT services have been outsourced. External company employees are authorized, in case of need ,to directly contact the request reporters and communicate about the requests.
All service requests from the brewery company, that need to be resolved by the External Services company, are currently sent there by e-mail. This causes the communication bottlenecks and breakdowns. For example, if some important details in the service request are missing then the External Service company employees need to write back and ask for them. These e-mails are replied by either Service Desk agents or directly by request reporters. It is difficult for the External service company to maintain the required Service Level Agreement.
Request reporters, Service Desk agents and External Service company are all unhappy because of this communication chaos.
It is even more frustrating for the External service company employees to use e-mail because they use Jira Cloud internally.
Problem solution
When both companies installed Exalate in their Jira instances, all they had to do was to agree which data was supposed to be synchronized. It turned out that the External Services company had some additional custom fields where they tracked their internal performance KPIs and they did not want this to be synchronized. On the other hand, the Security Officer in the brewery company did not want to agree to open their firewall to the traffic from Internet. Only the outgoing traffic was allowed and only for selected technical users. Exalate could deal with requirements from both sides simply out-of-the-box.
Both companies agreed which data should be exchanged and when. On the brewery side, the synchronization was triggered every time a service request was marked to be resolved by the External service company. In this way, the service requestors had the up-to-date status of their requests. On the other side, the External Service company agent could directly communicate with the requestor via comments and additionally implemented automation and reminders. In this way, the agent on the brewery side did not have to be involved in the ticket unless required.
The main benefit of this solution was removing the information flow chaos and bottlenecks which were caused by the e-mail exchange. The External service company SLA's became more transparent to the brewery company which resulted in better business relations. And for requesting users over time it did not matter who was the resolving agent because their requests were resolved in a timely manner and the communication was done in a tool that they know and understand.
Where can you learn more?
Watch my presentation on this subject, which I presented during the Deviniti Jira Day on 26 May 2021. I will be demonstrating a similar practical use case I discussed above, in a form of a quick walkthrough in two Jira systems
Was this helpful?
Thanks!
Bogdan Gorka
About this author
Atlassian Expert
JLAB
Poznan, Poland
10 accepted answers
1 comment