Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


how do I make a project private?


3 answers


I have created a scrum project in JIRA. However, the project is accessible to everyone. How can make it a project the project private i.e. visible and accessible to users only working on the project. 

Hi Derek, you can make a project private by limiting it's users & roles. If you're a JIRA admin, you can access these settings by clicking on the gear icon in the top-right, then selecting 'Projects'. Once the page loads, click on the project you want to update, and go to the 'Users and roles' section of the project settings. From here you can add a new user to a specific role by selecting the 'Add users to a role' option in the upper-right, enter the desired user and select the appropriate role, then click 'Add'. You can also remove users/roles from the list of existings users/roles by hovering over the user/role and clicking the trashcan icon.


Here's a couple of help articles that should give you further details on this process:


I'm spinning up a new team to manage a new ATS contract.
We've begun the procurement process and are starting to build a backlog or requirements.

One of the bidders is our current provider, for obvious reasons i need to ensure they do not have access to the new board.

I've created a new board and tried to ensure that only a few can access it. I've run a few tests and so far everyone can access it.

I've followed your advice from this post and others that I've found in this community, but I've been unsuccesful.

Please help.

Like Matt.Patman likes this

Although this answer is labelled Cloud it doesn't seem to apply to the current version of Cloud.  Am I wrong about that?

I believe the basic process still applies to cloud, but the admin sections may have changed names/labels on things since I provided my original answer.

If you are using a "classic software" project then the 'Users and roles' section is now called 'People'. If you are using a "next-gen software" project then the 'Users and roles' section is now called 'Access'.

The links I provided in my original answer should have been updated to reflect any changes in cloud, as those are maintained by Atlassian.

Like # people like this

Should we be using permission schemes in classic projects for scalability?

@Stefanie SullivanSorry, I'm not sure I follow your question. Permission schemes are required for Jira projects, as they determine who can access the project & what they can do.

For scalability on permission schemes, best practice is to use Project Roles to assign permissions, and then add Groups to said Project Roles, and then Users to said Groups. This makes it so that when adding/removing users, you do not need to alter the project's settings to add/remove individual users, and instead can add/remove a user to/from a group to maintain permissions.

Hope this answer helps, but if you still have questions please feel free to ask.

I meant to say should we be creating a custom scheme specifically for this one project that we want to restrict? 

Yes, any time you need a scheme that will only apply to one (or a few) project, then you should make a new custom scheme for said project...unless it already has it's own scheme that no other projects use, in which case you can simply edit that existing scheme.

Thanks so much. Would you recommend starting with a blank permission scheme?

Does just limiting the browse permission to a group restrict access to the whole project to others or do all the individual permissions need to be updated?

If you have a scheme that has most of the permissions you want, starting with a copy of that would be fine...but yes, generally you would start with a blank scheme and add users/groups/roles to permissions as needed for said project.

The browse permissions determines who can see said project, so limiting that to a group would mean only members of that group can see it (aside from admins who would be able to see it on the admin backend). However, best practice for permission schemes would be to set permissions based on project roles, and then add groups instead the appropriate roles, and users into groups. This makes it so you have less project administration to do later, as you simply have to add/remove users from specific groups to gain/remove access, rather than needing to maintain group/user permissions on each individual project. This article may help:

thank you. Can I use roles if I am not using next gen projects? Our current roles are OOTB and not specific to this project. I did create a group for that. If I were to use roles would I need to create new project specific roles?

Roles are a globally managed item, so they can be used across projects...and they are definitely available for standard projects as they've existed long before next gen projects were a thing.

Roles come into use on a project when they've been assigned in a scheme or other settings that allow roles. So while you manage them globally across your whole Jira instance, they won't actually be used unless you specify the one(s) that should be used in each project.

As for creating new roles, I would say that depends on what makes the most sense for your teams & terminology. There is no difference between various roles other than names, so it's all in how & where you use them that determines the differences between them. So if the default role names don't make sense for your usage, then creating new roles is always an option.

This article should help give a better overview of roles and their uses:

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events