How does product access work?

As an admin, you can configure product access for users in your organization in two ways:

1. Assign product roles

To give users product access, you must assign them a role in Organization admins are able to assign product roles. User access admins can also do this, but only for products they administer. Similarly, a site administrator can only assign roles within sites they administer.

2. Apply in-product permissions

This is an additional layer of access that gives more granular control over specific areas. For example, you can use in-product permissions to limit a user’s access to secret Jira projects or confidential Confluence spaces. Both organization admins and product admins can apply this level of permissions, but typically organization admins handle this.

You can also use groups to assign product roles or apply in-product permissions for multiple users at the same.

Assign product roles

As an organization admin, you can grant the default level of product access to users by doing one of the following:

A user access admin can also do these tasks, but only for products they administer. This means if a product's default group also includes products they don’t administer, a user access admin won't be able to grant access to that product.

Learn about common problems for user access admins managing groups

The following image is an example of a user who has been assigned a product role for Jira and for Confluence. This user was automatically added to the default groups when they were assigned a product role.

This user was not assigned a product role for the second Confluence product (

Image illustrating how adding a user to groups can give them access to products

Apply in-product permissions

If your organization needs confidential Jira projects or Confluence spaces, you might want to grant or restrict access based on a user’s role or employment status within your organization. For example, you may want to restrict access for contractors and vendors, but only allow access to certain spaces for your legal or HR teams.

In-product permissions can be set up by product admins from within the product and managed via groups from your organization at Groups can help you to apply and manage the same level of product access for multiple users in your organization, who have similar access requirements.

You can manage your in-product permissions from the following places:


Where to manage in-product permissions

Roles that can do this


Open Confluence and select the settings cog in the navigation bar.

Screenshot showing the Confluence settings top-right of the Confluence navigation bar

Learn about managing site-level permissions in Confluence

Confluence admin



Open Jira and select the settings cog in the navigation bar > Jira settings > System.

Screenshot showing how to access the Jira settings menu from top-right of the Jira navigation bar

Learn about project permissions and roles in Jira

Jira admin


Why do we need groups?

Groups can help you reduce the time it takes you to set up product access for multiple users. You can use groups to assign default product roles and to manage in-product permissions.

By creating groups to manage in-product permissions, you can precisely control access to confidential information for multiple users. Learn how to create and update groups

Like organization admins, user access admins can use groups to set up product access. However, user access admins can only set up access to products they administer. This means if a product's default group also includes products they don’t administer, a user access admin won't be able to set up access to that product.

Learn about common problems for user access admins managing groups

Users are added to certain default groups when you grant them access to products. For example, granting a user access to a product automatically adds that user to the default product access group. The default product access group is automatically created when you add a product to your organization. If you then choose to give the same user admin permissions as well, they’ll be automatically added into the default admin group too.

Using groups to assign product access

The following image is an example of how one group (All employees) may be created to manage access for multiple users to multiple products at once.

The group – Customer support team – is not a default product access group. In this example, one user has been added to this group, granting them access to an additional Confluence product ( that the other three users don’t have access to.

Illustration that shows how you can use different groups to assign product access to your users

Using groups to apply in-product permissions

The following image is an example of how in-product permissions can be applied to multiple users (in this case the Marketing group) using one group. In-product permissions are managed within the product, but you’ll set up the group and manage the group membership from your organization at

Illustration that shows how you can use a group to apply in-product permissions for user

Here’s a few examples of how you might use groups

Onboard new members of a team

Let’s see how we can make use of groups to onboard new members of an HR team. This team uses the following products and project spaces:

  • Confluence: used by everyone across your organization.

  • Jira Service Management: to store general HR tickets.

  • HR policies and procedures, a Confluence space for all general HR information.

  • HR personnel information, a Confluence space to store confidential information.

  1. From your organization at create a group. Let’s call it HR-team. We’ll use this group to manage access to all products for everyone in HR in your organization.

  2. Add the Confluence and Jira Service Management products to the HR-team group. This gives all group members access to spaces in Confluence (like HR policies and procedures) and to projects in Jira Service Management – excluding anything confidential.

  3. Then, we’ll create another group, let’s call it HR-confidential. This is the group where we’ll apply the in-product permissions for Confluence.

  4. From your Confluence settings, restrict default access to the HR personnel information space and allow access only to members of the HR-confidential group. Learn how to assign Confluence Cloud space permissions

When a new HR team member joins your organization, add them to the HR-team group to grant them access to Confluence and Jira Service Management

When people move teams

You can also use groups when someone moves teams. For example, if Omar is moving from the Legal team (let’s call it the Legal-team group) to HR, remove Omar from the Legal-team group and add them to the HR-team group. If Omar’s role requires access to the Confluence space that contains sensitive information, add them to the HR-sensitive group too.

Grant everyone access to a new product

Groups are also useful to grant access quickly when you add new products to your organization. Let’s say you want to grant the HR team access to Jira(a product you’ve added to your organization recently). You can grant this access to all members of the HR-team group from the product details page, or from the group details page.

Note that when you remove a user from a group, they will lose access to all products and product roles associated with that group. However, the user won’t lose access to any products you granted them access to by assigning a product role. For example, let’s say you granted Jane access to Confluence, not by adding Jane to a group but by assigning them a product role. Jane also happens to be in the HR-team group. Even if you were to remove Jane from the HR-team group, they’ll still have access to Confluence because you had previously assigned Jane a product role.

Additional Help