2.3 Site Access, Product Access Tiers & Global Permissions
Key Takeaways
- Jira Cloud access has three layers: site access, app (product) access that consumes a billable seat, and project access granted through permission schemes or team-managed roles.
- App access is managed by organization-level admins in Atlassian Administration, and a user in several groups for the same app still uses only one seat.
- Global permissions are granted to groups and include Administer Jira, Browse users and groups, Share dashboards and filters, Manage group filter subscriptions, Make bulk changes, and Create team-managed projects.
- Jira admins cannot manage users, import or export data, or edit system email settings; Jira Data Center's 'Jira System Administrators' permission doesn't exist in Cloud.
- Without Browse users and groups, a user only sees people who have Browse Projects in the project they're viewing.
2.3 Site Access, Product Access Tiers & Global Permissions
Quick Summary: Access management in Jira Cloud works in three layers: site access (can the user sign in to the site?), app access (does the user hold a billable Jira seat?), and project access (does a permission scheme or team-managed role let them into the project?). Global permissions sit across these layers and control site-wide capabilities such as seeing the user directory, sharing filters, bulk changes, and creating projects.
The Three-Layer Access Hierarchy
A foundational concept on the ACP-120 exam is understanding the distinct boundaries between Site, Product, and Project access. Conflating these layers leads to licensing overages and severe permission misconfigurations.
=========================================================================
LAYER 1: SITE ACCESS
URL Reachability: Can the user resolve and authenticate to https://acme.atlassian.net?
Configured via: Atlassian Organization / Site User Management
=========================================================================
|
v
=========================================================================
LAYER 2: PRODUCT ACCESS (LICENSING)
Product License: Does the user consume a billable seat for Jira Software?
Configured via: Atlassian Administration (app access)
Default Groups: jira-users-{site}, confluence-users-{site}
=========================================================================
|
v
=========================================================================
LAYER 3: PROJECT ACCESS (AUTHORIZATION)
Issue Visibility & Actions: Can the user view issues in Project PHOENIX?
Configured via: Project Settings > Permissions / Permission Schemes
Mechanisms: Browse Projects, Create Issues, Edit Issues, Project Roles
=========================================================================
Layer 1: Site Access
Site Access is the outer gate. It grants a user the right to authenticate to a specific site URL (e.g., https://acme.atlassian.net).
- If a user has Site Access but no Product Access, they can access their personal profile settings and public/portal resources, but navigating to Jira displays a "You don't have access to this product" error screen.
- Revoking Site Access immediately prevents the user from logging into the site entirely.
Layer 2: Product Access
Product Access governs software licensing and application availability. In Atlassian Cloud, licensing is group-driven:
- Every Atlassian Cloud product installed on a site (Jira Software, Jira Service Management, Jira Product Discovery, Confluence) has an associated list of Product Access Groups.
- When a user is placed into any group associated with a product's access configuration, that user consumes one billable license seat for that product tier.
- Default access groups are created per site and carry the site name as a suffix, for example
jira-users-{site}orjira-software-users-{site}for Jira, andconfluence-users-{site}for Confluence. Older sites may show shorter names such asjira-software-users. - Atlassian's default configuration also puts these groups in a Users project role, so members can browse and create issues in projects that use the default permission scheme (unless issue security restricts them).
Exam Trap: You can configure multiple groups to grant access to the same product (e.g.,
engineering-staffandcontractor-devscan both be added to the Jira Software product access configuration). However, putting a user into multiple groups linked to the same product on the same site still consumes only one product license.
Layer 3: Project Access
Having a valid Jira Software license does not grant access to any specific Jira project! Project visibility is governed strictly by the project's Permission Scheme.
- To see and search for issues within a project, the user must be granted the Browse Projects permission within that project's permission scheme (typically assigned via a Project Role such as "Developers" or "Viewers").
- An employee can be a fully licensed Jira Software user, but if their project role or group is omitted from a project's permission scheme, that project is completely invisible to them in navigation menus, search bars, and JQL queries.
Product Access Tiers and License Management
App (product) access is managed by organization admins (or site admins and user access admins, depending on the organization's user-management model) in Atlassian Administration, not by Jira admins.
Default Product Access Groups
Administrators can designate one or more groups as Default Access Groups. When new users are invited to the site or provisioned via SCIM without specific group assignments, Atlassian automatically adds them to the default product groups.
Best Practices for License Governance:
- Disable Unintended Defaults: If your organization uses Jira Service Management for 5,000 internal portal customers and Jira Software for only 200 software engineers, ensure
jira-software-usersis not set as a default group for new invites. Otherwise, every invited portal user will accidentally consume an expensive Jira Software license seat! - Monitor Inactive Users: Review last-active dates in Atlassian Administration and remove app access from people who no longer need it to reclaim billable seats.
| Access Configuration | Function | Billing Impact | Scope |
|---|---|---|---|
| Site User | Can authenticate to the cloud site | No direct cost (unless assigned a product) | Site URL level |
| Jira Software User | Can create, edit, and estimate backlog issues, sprints, and boards | Consumes 1 Jira Software seat | All permitted JS projects |
| JSM Agent | Can manage queues, respond to customers, transition service tickets | Consumes 1 JSM Agent seat | All permitted JSM projects |
| JSM Customer | Can submit requests via customer portal, view own tickets | Free (unlimited portal users) | Service Project Portal only |
Global Permissions in Jira Cloud (Blueprint 1.3)
Permission schemes control actions inside projects. Global permissions control site-wide capabilities. They're managed in Settings > System > Global permissions, and blueprint 1.3 stresses two facts: know the purpose of each one, and remember that global permissions are granted to groups. You can't grant a global permission to a project role, because project roles only mean something inside a project.
| Global Permission (Jira Cloud) | What It Allows | Typical Holder |
|---|---|---|
| Administer Jira | Create company-managed and team-managed projects; create and edit work types, fields, workflows, screens, and schemes for fields, permissions, and notifications; log in regardless of access restrictions | jira-administrators |
| Browse users and groups | See all users on the site in user pickers and @mention suggestions | Internal staff groups |
| Share dashboards and filters | Share filters and dashboards with other users, groups, projects, or the whole organization | Groups that build shared reports |
| Manage group filter subscriptions | Create and delete filter subscriptions that email a group | A small reporting or admin group |
| Make bulk changes | Edit, move, delete, or transition multiple issues at once (the user still needs the matching project permissions) | Leads and admins |
| Create team-managed projects | Create team-managed projects only (company-managed projects require Administer Jira) | Often restricted in governed sites |
| Manage custom onboarding | Create custom onboarding content for new users and view its analytics | Enablement team |
Apps can add their own global permissions, so you may see extra rows on a real site.
What a Jira Admin Can't Do
Atlassian's documentation is explicit: users with Administer Jira cannot manage existing users or invite new ones, import or export data, or edit system email settings. Those are organization-level (org admin or site admin) tasks. Expect a question that asks which admin can create a site backup or add a user. The answer is never "any Jira admin".
Browse Users and Groups
This permission controls how much of the user directory someone can see:
- With it: user pickers (Assignee, Reporter, custom user fields) and @mentions can find anyone on the site.
- Without it: Atlassian documents that the user only sees people who have the Browse Projects permission in the project they're viewing. They can still assign work to project members, but they can't discover colleagues outside the project.
This is a common way to limit what contractors and external collaborators can learn about the wider organization.
Share Dashboards and Filters
Users without this permission can still save filters and build dashboards, but only for themselves. With it, they can share with groups, projects or project roles, specific users, or everyone in the organization. Sharing with the public (anonymous visitors) is available only if a Jira admin turns on Public sharing in Settings > System > General configuration, and Free plans can't be made public.
Manage Group Filter Subscriptions
Any user who can see a filter can subscribe themselves. Subscribing a group requires this permission, and the subscriber can only choose a group they belong to. Chapter 9 covers how group subscriptions evaluate results for each recipient.
Make Bulk Changes
This global permission unlocks the Bulk change tool, but it never overrides project permissions. To bulk-move issues, a user needs Make bulk changes plus Move Issues in the source project and Create Issues in the destination. Chapter 9 covers bulk operations in detail.
Create Team-Managed Projects
Anyone holding this permission can create team-managed projects and configure them locally. Sites that want every new project built from governed company-managed templates remove broad groups from this permission. Existing team-managed projects are unaffected.
Licensed vs. Anonymous Access
The Domain 1 description in the blueprint mentions licensed and anonymous access. Three facts cover most questions:
- Browse Projects doesn't require app access. Atlassian notes that the Browse Projects permission can be granted to any user who has access to your site, and granting it broadly is how a project is made visible to people without a Jira license.
- Public (anonymous) access is a deliberate choice. A project becomes visible to anonymous visitors only when its permission scheme grants Browse Projects to the public (anyone on the web). Free Jira sites can't be opened to the public.
- Some features never work anonymously. The
currentUser()JQL function only works for logged-in users, so filters meant for anonymous viewers shouldn't use it. The Permission Helper can test anonymous access: leave the user field blank.
Protecting the User Directory
Organizations that host contractors alongside employees combine several controls:
- Withhold Browse users and groups from contractor groups, so they only see members of the projects they work in.
- Use project roles, not broad groups, to grant Browse Projects, so contractors see only the projects they're added to.
- Use issue security levels for sensitive issues inside a shared project (Chapter 3).
- Use Atlassian Guard's external user policy when external collaborators must verify their identity before viewing your content (Chapter 2.2).
A senior Jira administrator discovers that non-technical business managers are creating uncontrolled team-managed projects, resulting in hundreds of orphaned custom fields and broken corporate JQL rollup reports. The executive steering committee mandates that all new projects must adhere to standardized company-managed project templates provisioned exclusively by the central Jira tools team. Which configuration change directly enforces this policy without impacting existing projects?
An external QA consultant has Jira app access and is in the 'Developers' role of project ALPHA. The consultant can assign ALPHA bugs to ALPHA developers, but when they try to @mention a finance analyst who works only in another project, no match appears. What is the most likely reason?
The finance director at a software enterprise notices that the monthly Atlassian Cloud invoice for Jira Software increased significantly following the launch of a new internal IT helpdesk. Upon auditing user directories, the administrator discovers that 120 customer support technicians—who only require access to Jira Service Management queues—were inadvertently placed into a security group that is mapped to Jira Software Product Access. What is the most efficient administrative remedy to correct the billing overage without interrupting helpdesk operations?