Study guide
2.3 Site Access, Product Access Tiers & Global Permissions
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
2.3 Site Access, Product Access Tiers & Global Permissions
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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} or jira-software-users-{site} for Jira, and confluence-users-{site} for Confluence. Older sites may show shorter names such as jira-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-staff and contractor-devs can 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-users is 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).