Collaborating with External Users in Jira and Confluence

External Share article header image

Sometimes the perfect person to help you with a project is someone who doesn’t have access to your Jira or Confluence. But to get that person’s help, you have to share the information in your Jira or Confluence with them. How? Well, there’s two ways.

  1. Copy or export the data into something else, or take screenshots, and attach it to an email (the long, tedious, complicated way that means the data isn’t live anymore)
  2. Give the user access to your Jira or Confluence by buying them a new license, and cross your fingers hoping that all your permissions and restrictions are set up correctly (the super-expensive and really-not-very-sensible-if-you-want-your-data-to-be-safe way)

Alright, we lied.

There’s a third way. And it’s the best way. Sure, we’re biased. We made it. But it really is. And it’s called External Share.

Technically, External Share is two apps: External Share for Jira and External Share for Confluence. These two apps give you the ability to share live content from Jira tickets or Confluence pages with anyone you choose—totally securely.

Let’s start at the beginning.

What is an external user?

An external user is anyone who does not have direct access to your Jira or Confluence instance. Usually we’re talking about other companies or contractors you need to outsource a function or piece of work to. Not that external users have to be outside of your company. They could be in the finance, sales, or support team, or work in a foreign branch and just not have access to the particular Jira or Confluence instance you’re using.

Here are some example scenarios.

  • Your team is working with an external supplier. You don’t want to give them full access or a license to your Jira instance, just the ability to view the particular issues involved with the current project or purchase.
  • The client’s legal team is asking to review contractual documents. You’re still writing the draft and you want to be able to update and amend the document after it’s sent.
  • An outage is taking place and you want to share the updates with a select group of users. They need to be able to add comments but you don’t have time to set them all up with Jira licenses and check they have the correct access.
  • A product developer is creating designs for a new product but needs input from a customer or partner as they work on it.

Now let’s talk through the problems with the first two ways of sharing the information necessary in these scenarios in more detail.

Er, do what now?

If there’s no easy or secure way to share the information you need to share, the average user will probably find a clumsy, long-winded, and totally inefficient way of doing it. Or, if it’s too much effort, they just won’t share the information at all. That means communication gets restricted and the whole company slows down and becomes siloed.

Share information in Confluence and Jira to avoid information Silos

What’s more, if you do use screenshots or export the data to a PDF or CSV file, the data stops being live. A PDF is static. A screenshot is static. An email is static. But Jira issues and Confluence pages are dynamic. The data in them is real-time. This is something you want to retain when you share the information. You certainly don’t want to be sending new screenshots every time something changes. That’s, you know, a massive pain in the posterior.

Basically, if speed, agility, flexibility, and security are important to you, then you should be working hard to avoid all this.

Okay, so why can’t I just open the door and hope for the best?

Well, yes, you could do that. But you’d have to buy the door first, and a new Jira or Confluence license is a very expensive door.

Imagine how much you could save if you didn’t have to buy every person you need input from on a project a whole new license. And Confluence licenses can add up very quickly. This is despite the fact that most users only need to view a very small number of pages, especially when they’re getting started.

The second problem with opening the door to your Jira or Confluence instance is that it’s difficult to keep track of what’s coming, and more importantly going, through that door.

Out of the box, every Jira and Confluence instance can be configured to “restrict” users to only see particular projects or spaces. But this is security by “hope” because in order to work as intended, it needs to be set up perfectly right from the start, for every possible use case. Otherwise, you’ll have no idea what’s restricted, what isn’t, and who has access to which bits. In essence, who’s to know how wide the door is open or how much is escaping through it.

Take a deeper dive into Jira and Confluence and you’ll be able to restrict visibility to particular issues (Issue Security Schemes) and individual pages (Page Restrictions). But outside a small circle of power users and super admins, how many people reading this know what an Issue Security Scheme is?

Alright, alright. You’ve worn me down. Tell me about External Share.

We promise you won’t regret it. Here goes.

External Share for Jira and External Share for Confluence let you share secure and unique links to your Jira issues or Confluence pages with whomever you choose. These links have virtually-impossible-to-guess URLs with 16-character codes, but you can protect them further by adding time limits and passwords (more on that later).

In the External Share view, data is shown on a lightweight, fast-loading page. (For anyone that’s ever been frustrated with how slow Atlassian Cloud loading times can be, this will feel lightning fast!) And importantly, that data is live. All the external user has to do is refresh the page and there it is.

So, instead of this nonsense…

Static documents are bad for collaboration

… you can simply do this!

Review and amend contract documents in Confluence

So the external user can see the data. Can they do anything to it?

Security was top of mind when we developed External Share and enabling our clients to keep control of their data is very important to us. So there are currently only two things that external users can do when viewing an External Share link.

They can add comments, like so.

External users add comments to confluence from the External Share view

And they can add attachments (very useful if someone needs to upload a document or a screenshot).

external users add attachments to confluence pages and Jira issues.

Otherwise, the issue or Confluence page in the External Share view is read-only. Only the in-house Jira/Confluence user has the power to change anything.

Can’t the external user transition issues? That might actually be useful!

As a matter of fact, we agree. Since the external user is working on the issue, it would make sense to allow them to change the status of the issue in the External Share view. Although this feature is not available yet, it’s at the top of our backlog, so keep an eye out.

You mentioned protecting External Share links with passwords and time limits…

Yes, we did. Both are as easy as falling off a log. Here’s how you create an optional password that an external user will need to enter to view the External Share link.

protect Confluence pages access with passwords
protect Jira issue access with passwords

And of course you probably don’t want your External Share links floating out in the ether forever, which is why you can set optional expiration dates, after which the links expire and become inactive. In Global Settings, you can also set the maximum life of all links from the day they are created, e.g. one month.

Jira issue expiration date

And what about restricting who can create External Share links?

Restricting who can create links might not sound like a problem if your team is small (10-20 people), but if your company has thousands of users, you need granular control over the sharing of content.

In External Share, just go to the Global Settings menu in the project or space. By default, any logged-in user is able to create, edit, and delete External Share links in any project or space they have permission to access. All you need to do to change that is go to the Permissions section and select the “Groups” you want to be able to create links. Go deeper than this and select particular “Project Roles” to allow administrators in specified teams to control External Share links in their own projects and spaces.

Permission role restrictions in Jira

And it’s definitely going to save me money, yeah?

Yes. To be more specific, a Jira Cloud license per user is up to five times more expensive than External Share, and that’s just for Jira Software.

The biggest savings come from using External Share to work with one-off or infrequent collaborators. If someone’s hardly ever going to log in, or only needs to view the odd Confluence page occasionally, there’s really no point having them consume a whole Jira or Confluence license. That’s just dead money.

For more details, and to see all the available features of External Share, check out our documentation below:

Start your free trial of External Share for Jira and External Share for Confluence right now from the Atlassian Marketplace, or check out the demo video below.

Morgan is a Seattle born and raised lover of rain and software, particularly software that isn’t a pain in the bum (like some Atlassian tools can be). This is why she’s a Custom Charts for Jira superfan and jumped at the chance to contribute to the solution herself. She specializes in Agile, Scaled Agile, and ITIL in the Atlassian app space, loves a cross-country road trip, and is on a mission to find the cutest coffee shop in every town she visits.