Manage your organization’s Atlassian accounts
Gain control over your employee's Atlassian accounts.
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 admin.atlassian.com. 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.
As an organization admin, you can grant the default level of product access to users by doing one of the following:
assign a product role when you invite a new user to your organization
assign a product role to give product access to an existing user
add one or more users to a group (any product role you add to a group grants access to all the group members)
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 (acme-support.atlassian.net).
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 admin.atlassian.com. 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:
Product | Where to manage in-product permissions | Roles that can do this |
---|---|---|
Confluence | Open Confluence and select the settings cog in the navigation bar. | Confluence admin
|
Jira | Open Jira and select the settings cog in the navigation bar > Jira settings > System. | Jira admin
|
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.
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 (acme-support.atlassian.net) that the other three users don’t have access to.
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 admin.atlassian.net.
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.
From your organization at admin.atlassian.com 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.
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.
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.
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.
Was this helpful?