User, Group, and Role Management
Three layers, three purposes
An Atlassian account is the identity (email plus verification). Product access decides whether that identity can open Jira Software, Jira Service Management or Jira at all - usually via a default access group such as jira-software-users. Groups are site-wide containers used for product access, global permissions, project permissions and notification recipients. Project roles are scoped to a single project and can contain individual users or groups.
Why roles usually win
Roles make schemes portable. A single permission scheme can be attached to fifty projects, and each project names its own administrators, developers and viewers through its roles - so people can be added or removed per project without touching the scheme. Groups, by contrast, cut across every project that grants to them, which is why "grant to a group" answers often widen access unexpectedly.
Traps
- A user with product access but no group or role granting Browse Projects sees an empty Jira.
- Deactivating a user frees the licence and preserves history and mentions; deleting is irreversible and the account cannot be restored the same way.
- The
atlassian-addons-project-accessrole must exist in projects used by Marketplace apps, or app features silently fail. - Nested groups: do not design around them. Behaviour has varied across Cloud products - keep membership direct or, better, use roles.
- Removing someone from a group can remove notifications and permissions at the same time.
Rule of thumb: grant permissions to roles, put people in roles, and reserve groups for site-wide concerns such as product access and global permissions.