Hi,
We have a Atlassian instance in cloud connected to our IdP (Entra ID) with a bunch of users in various access group.
A bunch of our users (non Atlassian users/non licensed) is going to be invited as guest to an external Atlassian instance for an external project. But as our domain is "locked" and these users is not in "our" Atlassian instance they will be unable to access the external Atlassian instance.
How do we solve this? Do we invite our users as guest to our instance so that they are then able to access the external instance when they receive the invite?
And No, we will not buy any licenses for these users.
Hey, Peter!
This is a common challenge when organizations are on Atlassian Cloud with domain-claimed accounts and want to collaborate externally. A few key points:
If your company has claimed your domain, all emails under that domain are “owned” by your organization in Atlassian Access. That means users with your email domain can’t just be added as guests to another Atlassian site.
Simply inviting them as guests in your instance won’t help — domain claim restrictions still apply when they try to join the external site.
This said, these are the most common workarounds are:
External email addresses: Have those users join the external Atlassian site with a personal / non-company email (e.g. Gmail, Outlook). It avoids the domain restriction.
Federation agreement: If the collaboration is long-term, the two organizations can agree on how to federate or whitelist specific accounts. This usually requires admin alignment.
Limited access through other tools: Sometimes it’s easier to expose only the relevant information (dashboards, reports) in Confluence/Jira, instead of giving them direct access.
_____
Extra insight from practice:
At Deiser we’ve seen similar cases where external collaborators couldn’t be licensed in Jira/Confluence. In those situations, we solved it by setting up automations and email alerts:
Key updates or status changes were pushed automatically via email to those external stakeholders.
They stayed informed without needing an Atlassian license.
Internally, the Jira project remained the single source of truth.
It’s not always as seamless as direct access, but for many customers it’s a very efficient compromise.
_____
My recommendation: if you really need them “inside” the external instance, go with option #1 (personal email accounts). If visibility of information is enough, automation + email alerts can save you both licenses and admin overhead.
Hope this helps clarify the options!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.