nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to onboard external user to a Jira Software instance

Vikrant Yadav

Hi Experts,

Need your expert advice.

In our Jira instance, there are 200+ project out of which 73 are Team-Managed project.

Now we received a request to onboard external users, we want external will only see Project A rest other 199 projects won't be visible to them.

I am thinking to update the Browser project permission for all the Company Managed project and for Team Managed project make them private. But in Team Managed project admin can change the project from Private to Open. Is it a good and sclable solution ?

OR we create a separate instance for this team, as this team needed 4-5 Jira projects collboation with external users and onboard external user to this new instance. So in our main instance, we no need to make any permission scheme changes and no breach of security.

Kindly suggest some reliable and scable solution and best approach to do this.

Accepted answers

Walter Buggenhout

Hi @Vikrant Yadav,

Placing team managed projects and scalable in the same sentence quite honestly in itself isn't the best combination. They are designed to let teams organise themselves in isolation and I always strongly recommend not to use them for anything outside that scope. Having said that, if you could turn that into a company policy and have them set up as restricted by default, that might theoretically work (and yet again: the concept of team managed projects opposed to company policy might bring you to the point where you're facing other challenges yet again.)

If you want to get to a solution that scales, I'd always recommend to stick with company managed projects. Limit the number of permission schemes by making them role-based as much as possible and with as limited exceptions as possible. Make sure to remove public access or any logged in users from the browse project permission and take control of your permission system by linking groups to project roles.

Hope this helps!

All comments

Walter Buggenhout

Hi @Vikrant Yadav,

Hope this helps!

Vikrant Yadav

@Walter Buggenhout Thanks for your guidance!

We already have TMP, not it's not feasible to stick with Company managed project only.

In our instance, there are lots on Team-Managed project, for now if i make them Private, project admin still have rights to change project to Open or Limited.

For Company managed, I will update Browser project permission.

Are you suggesting converting Team-Managed to company managed project ?

In Company managed project, if I implement role based permission, then project admin can add external to a project role and external user will get access to their project. This thing also our upper authority don't want to allow.

Creating instance doesn't work ?

Walter Buggenhout

Hi @Vikrant Yadav,

No; I understand you have an existing situation and that it is not easy (or maybe not even feasible) to convert lots of projects to a different type. There is a lot to such a change.

Consider my response as best practice advice. If it is not feasible to convert your TMP's to CMP's, then you need to work with the situation as it is and:

make them private;
accept that project admins can change permission settings there;
communicate the risks of incorrect permission settings on security
(regularly review permissions across all projects in your instance and follow up with project admins if they are not doing things correctly)

You can remove the permission to create new TMP's for non-admin users in your instance to make sure no new projects of that type are added without admins knowing about it.

Is this a scalable solution - to refer to your initial question? No, probably not. But it is a tradeoff you'll need to make.

About this:

In Company managed project, if I implement role based permission, then project admin can add external to a project role and external user will get access to their project. This thing also our upper authority don't want to allow.

Theoretically, yes. But why would any project administrator randomly add external users to their project if they do not work with those users? Similar as with the team managed projects:

communicate with your project admins about the importance of permissions;
if needed, regularly perform an audit and act if necessary.

Creating instance doesn't work ?

Yes, of course it does. But that comes at a cost too. Your internal users who work in multiple projects (some internal, some with external users) will have to use different URL's to find their work. If you want shared reporting, dashboards, to do lists across the different projects, that will no longer be possible. If work from an internal project has a link to the external projects, you won't be able to properly define that. And so on ... And at the same time, the problems you mention about it being possible that users don't define permissions correctly exist in that new site in exactly the same way.

In other words, managing permissions will always require responsibility and awareness of everyone involved. There's different technical options to implement them, but you will always need to control the human factor somehow through procedures, checks and balances.

Bogna Krystian_Deviniti_

Hi @Vikrant Yadav

If you're considering setting up a separate, clean Jira instance, Issue Sync Pro , developed by Deviniti, can be helpful. This app allows you to automatically synchronize issues between your internal Jira and an external-facing instance.

Here's how it works:

External users log requests, bugs, or tasks in their instance.

Internal teams work in the primary Jira instance.

A two-way sync ensures that status, comments, attachments, and other details remain aligned

Full disclousure, I work at Deviniti

Vikrant Yadav

@Walter Buggenhout Thanks a lot for sharing the best practices.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud