Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Change default Jira group


We need to use a different default group when a new user is created. We have read the global permission question:

But is not clear how we should proceed with jira 7.3. We see the following options: 


Jira Administrators

Browse project

Create shared objects

Manage group filter

Bulk Change



List of users groups



2 answers


We need to automatically assign a group that doesn't use jira licenses during the creation of new users.


I see this message in the URL you sent:

Looks like we’re off the beaten track


Good it seems to work fine with the links now :-) 

In the administration > Applications > Application access in the top right you have a button to set the default user access.

This way when creating a user no application access will be checked by default but you will need to add this user manually to a group.

To be sure I understand in order to help you: why does a user need to be part of a group without application access?

Thanks for the Info, this is what we're looking for:

When a user is automatically created (first-time access), we need to assign them only access to service desk as a customer. By doing this, we can have control over the licenses we are using and reduce the manual work of moving the users from one place to another.

Is this possible?


Ok so it's all about your customers. How do you create the users login? Do you create them manually, via an Active Directory or do you enable public sign-up (see the paragraph about Jira Service Desk to know how to this)?

If you want that your customers create their own login they have to do it via the customer portal. This way they will automatically be in the "Service Desk Customers role" which does not count for a licensed user.

See documentation about managing access to your service desk and about setting up service desk users .

Well, I also found it inconvenient that all new users are automatically added to the default group (in my case, confluence-users) even if you indicate an explicit group on invite that already covers all the permissions they need. And that this group, by default, gives access to all spaces on my product (Confluence).

To avoid troubles, I do the following:

1. Create one custom group per space (project) and invite users working on that project to this custom group. In project Space Permissions, just add that custom group with the usual permissions to add pages, comments, attachments, etc.

2. For each project in Space Permissions, remove all permissions on the default group (here, confluence-users). Just click on Edit Permissions, Select All, then Deselect All, Save all. The default group will be removed from the group list after that (as only groups with at least one permission are shown). I found no way to set default permissions on new Spaces for that group, so for every new Space, I must remember to do this (together with 1.).

3. Remove every new user invited from default group (confluence-users) manually.

Technically you only need to do 2. (default group has no permissions) or 3. (user is not in default group), but because everything is added automatically, if the user happens to login between the time you invited them, and did either 2 or 3, they will, for a short time, be able to access all your Confluence products. So it's safer to do 2. for each Space anyway, as unlike 3., you can do it once per space, before inviting a user.

I really wish the process was more streamlined (for instance, like GitHub, you would manage access per user or per team, in a very clear manner; Atlassian introduced the concept of teams but it's only used for communication, so we still need groups; which would work fine if not for unexpected default group permissions). And that Atlassian would warn you for every user given permissions to all your spaces. Since I've myself only realized it quite late, I wonder how many teams are currently misconfigured with permission leaks at the moment...

Suggest an answer

Log in or Sign up to answer