As Jira grows ever more ubiquitous, it’s increasingly necessary for larger and more diverse groups to communicate and collaborate on projects in real-time. The ancients’ rituals of emailing screenshots are embarrassingly outdated for software-enabled teams that bought Jira to avoid email-chain siloes and the disheartening disaster of discovering efforts have been duplicated due to a lack of real-time project management.
Fear not! We’ve written this handy guide of three options for secure collaboration with external users in Jira.
For Jira out of the box, Exalate, and External Share, we’ll cover:
- The Security Considerations
- The Pros & Cons
- Who They are Best Suited for
1.) Buy them a Jira license:
The first option to consider seems the most straightforward. Give individual access to your Jira, by giving each person a seat.
These vary heavily depending on who you’re sharing access with, and what you’re storing on your Jira.
If you’re sure there’s nothing you wouldn’t mind an outsider seeing (and everyone on your instance knows to keep it that way), open the circle and pull up a seat!
For larger instances, the cost of an extra seat will be rendered proportionally insignificant, but security procedure, compartmentalization, user permissions, and management will become a more important and cumbersome task.
How to do it:
- Set up permission schemes to restrict access to specific groups, project roles and users.
- Configure default group membership when you add a new user.
- Configure default project role membership when you create a new project.
- Deactivate accounts when users leaves.
Everyone has access to all Jira features, dashboards, and reporting, and can use all the same add-ons your teams use.
Smaller instances may have to consider the costs before they upgrade their user tier. Setting up permission schemes requires a lot of technical work, and requires the system to be completely air-tight. A single misconfigured project could allow users to see restricted data. Take care with this because: complex security schemes hurt performance for all users. As Atlassian themselves say:
Who it’s best suited for:
Teams with a full-time Jira Admin with technical skills, a strictly followed process, and the time to set up every Project and Space owners’ permissions properly. You’ll also need to be confident everyone at your organisation is following your procedures.
It will required time scheduled for user management, and a process in place to remove people’s access as required.
In short, this is the best approach for an organization with a big Jira instance, set up with best-practice processes, and good training that’s looking to share access with a small number of trusted external users.
2.) Exalate – Mirror your Jira!
The Exalate add-on makes it possible to run a realtime clone of every part of a Jira instance to another, using a uni-directional (or sometimes bi-directional) integration. There are also options for whether to share custom fields or attachments.
This is the mother of solutions, especially if you’re looking to clone and integrate multiple instances of Jira, ServiceNow, Zendesk, and Github merged onto one platform.
You will lose a lot of oversight on what the other side is doing with your data. This is fine when you trust them. Your teams must remember to only share the right things, and remove access at the appropriate time, as everyone on both instances will need to remember they’re sharing externally, as well as potentially housing someone else’s data.
How to do it:
There’s a detailed step by step guide: how to synch two jira instances using Exalate
But the TL:DR version is:
Jira instances, ServiceNow, Zendesk, Github
- Map a workflow that works for both teams. The workflows don’t have have to be identical, but you will have to map how they work, and what changes in one mean for the other.
- Choose the most appropriate option from one of their many templates, about what you want to share, and what you don’t.
- Install Exalate on both instances.
- Exalate each issue you want to copy.
5. Customize Jira Synchronization Rules Through Scripting:
6. If any errors occurs, you can always seek assistance from the Exalate team.
Backup! All things are duplicated, and you have two teams singing off of the same hymn sheets. If you have Jira, ServiceNow, Zendesk, and Github, this is the way to have a cross-platform single source of collaboration promised land, all merged onto one place.
You’ll need two instances of Jira, and both must have the add-on installed. This won’t suit all budgets, especially if you won’t get value from all of the features and integrations
It also requires work to ensure the integrations are set up properly, especially if the two instances have heavily customised workflows and different addons. You’ll also need to do basic coding and maintenance to get the replica data filter processors working.
Who it’s best for:
Making a purpose-built small instance for a collaborative project sharing with an outsourced development house, or a branch in another country. Work will be required to ensure reports work on both instances.
3.) Then There’s External Share
Sometimes, you only need to share a few issues with external users. That could be an individual contractor or consultant you’re not ready to hand the keys to the kingdom yet. Sometimes it’s a specific issue you want to share with a customer, a supplier, or even a sister or daughter company. Sharing limited information, for a limited time with specific individuals would be hard out of the box with Jira, or even with Exalate.
That’s where External Share for Jira and Confluence come in.
Make sure admins know the features: The length all links are live can be restricted by default (e.g. 1 day or 1 week).
Enforce password protection on all links, so only those with the link, and with the password can receive access.
Admins should review how many links have been created, and choose to remove or change sharing permissions. If in doubt, it’s easy to turn links off, and turn them on again, or delete them as appropriate.
How to do it:
There’s detailed documentation here that explains how to share external links to Jira tickets but the short version is:
1.) Click External Share
2.) Choose which sharing options you want for your security and click to send via email.
3.) If you’ve set a password, it’s good practice to send that separate to the link, following your own security procedures. They’ll have to enter the password to view the link.
4.) If you’ve enabled permissions to add comments and attachments, anyone with the link and password is now free to do so.
5.) You can review which links have been shared, and turn them off or delete them as needed.
It’s quick to setup and use, a no nonsense way to easily share specific issues with individual users securely.
It doesn’t have a lot of the advanced features of Exalate, so it’s more suited to sharing individual parent and child issues, rather than whole epics or instances.
Who it’s best for:
Medium-sized companies that want an easy way to quickly share specific information with named individuals while retaining control and security over the rest of the information on their instance.
It’s particularly popular with contractors and consultants as a quick way to get access to the issues they need, especially as the lite version of the app is free, and easily set up.
It can also be used to reduce Jira Service Desk agent licences by allowing non-agents to add public comments and attachments directly to issues.
Learn and Collaborate More:
Check out this link to learn more about External Share for Jira.
Alternatively, if you’d like to share Confluence Pages, externally visit External Share for Confluence on the Atlassian Marketplace, or for more information, here’s a blog on Sharing Confluence with External Users.
If you have any other tips and tricks for collaborating with external users using Atlassian Jira and Confluence, please share them with the community, and let’s update this blog together.