Study guide
4.2 Project Templates, Project Keys & Project Categories
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
4.2 Project Templates, Project Keys & Project Categories
Key Takeaways Explain This Topic AI
Project templates set up a project's initial configuration; company-managed projects created from templates get their own single-use schemes unless you share an existing project's configuration.
Project admins can edit the project name, URL, description, avatar, lead, and default assignee, but only organization, site, or Jira admins can change the project key.
Project keys must be at least two characters, start with an uppercase letter, and use only uppercase letters or numbers.
After a key change, previous keys are saved so old links, filters, and queries keep working, and the old key can't be reused until it's deleted.
Project categories group projects for navigation and JQL (category = 'X') but enforce no security or permissions.
Last updated: September 2026
Project Templates, Project Keys & Project Categories
Configuring an enterprise Jira Cloud instance requires establishing consistent structural taxonomies across hundreds of disparate initiatives. Administrators must guide project stakeholders through the selection of appropriate Project Templates , establish and maintain immutable Project Keys , and organize projects into coherent Project Categories for portfolio-level visibility. Each of these mechanisms plays a distinct role in instance architecture, search performance, and administrative scalability.
Project Templates Across the Jira Cloud Suite
When creating a project via Projects > Create project , Jira Cloud presents a catalog of templates categorized by product subscription: Jira Software , Jira Service Management , and Jira Work Management (now integrated across Jira platform business projects). JIRA CLOUD PROJECT TEMPLATES
- Jira Software (JSW) Jira Service Management (JSM) Jira Work Management (JWM)
- ┌────────────────────────┐ ┌─────────────────────────────┐ ┌───────────────────────────┐
- │ • Scrum │ │ • IT Service Management │ │ • Project Management │
- │ (Backlog, Sprints, │ │ (Incidents, Changes, │ │ • Task Tracking │
- │ Story Points) │ │ Problems, Service Reqs) │ │ • Process Control │
- │ • Kanban │ │ • Customer Service │ │ • Content Management │
- │ (Continuous flow, │ │ • General Service Desk │ │ (List, Board, Calendar, │
- │ WIP limits) │ │ (Queues, SLAs, Portal) │ │ Timeline, Summary views) │
- └────────────────────────┘ └─────────────────────────────┘ └───────────────────────────┘
- 1. Jira Software Templates (JSW)
Scrum : Designed for iterative software development teams practicing timeboxed sprints. Pre-configures issue types such as Epic , Story , Task , Bug , and Sub-task . Generates an active Backlog view, sprint planning mechanics, velocity tracking, and estimation fields (Story Points).
Kanban : Designed for teams delivering work in a continuous flow. Pre-configures a visual Kanban board with column-level Work in Progress (WIP) limits, cumulative flow diagrams, and control charts. By default, the Kanban backlog feature is disabled but can be enabled via board settings.
Bug Tracking : A streamlined software template focused specifically on defect capture, triage, and resolution cycles.
2. Jira Service Management Templates (JSM)
IT Service Management (ITSM) : Pre-configured with ITIL-aligned issue types ( Service Request , Incident , Problem , Change ). Automatically binds Service Level Agreements (SLAs), customer request types, service queues, change approval workflows, and an external Customer Portal.
Customer Service / General Service Desk : Optimized for external customer support or internal business requests without full ITIL complexity.
3. Jira Work Management Templates (JWM)
Designed for non-technical business functions (Marketing, Human Resources, Finance, Legal, Operations).
Emphasizes collaborative business views: List View (spreadsheet-style inline editing), Calendar View (date-driven tracking), Timeline View (lightweight Gantt-style dependency tracking), and Forms (drag-and-drop intake forms).
Template Selection and Initial Scheme Bindings
When a Jira Administrator creates a new Company-Managed Project from a template, Jira Cloud automatically creates a complete set of dedicated, single-project schemes prefixed with the project name or key (e.g., DEMO: Software Development Workflow Scheme , DEMO: Software Development Issue Type Scheme ).
Warning
The Scheme Sprawl Trap : If administrators continuously create company-managed projects using default template generation without intervention, the instance will rapidly accumulate dozens of near-identical workflows, screen schemes, and field configurations. Best Practice : Immediately after project creation, navigate to Project settings and re-associate the project with the organization's standardized enterprise shared schemes, subsequently deleting the orphaned auto-generated template schemes.
Project Details and the Project Sidebar (Blueprint 2.2)
Everything that identifies a project lives on Project settings > Details . Know who can change each item and what side effects each change has.
- Detail Who Can Change It What Happens When It Changes
- Name Project admin (Administer Projects) The new name automatically updates in filters across the site
Key Only organization, site, or Jira admins Every issue gets the new key prefix; the old key is saved as a previous key (details below)
- URL (company-managed only) Project admin Adds a link to external documentation shown in the project directory
- Description Project admin Shown in project settings and summaries
Category Company-managed: a Jira admin assigns it. Team-managed: the project admin can pick an existing category Changes category-based JQL, boards, and reports (no security effect)
Avatar Project admin Visual identification only
Project lead (now shown as space owner) Project admin Changes who "Project lead" resolves to in schemes, components, and notifications
Default assignee Project admin Can only be Unassigned or the project lead . To default to a specific person, make them the project lead. Unassigned requires the site setting Allow unassigned issues
The Project Sidebar
The left-hand sidebar is the project's navigation: board or list views, backlog, reports, releases, components, and admin-added shortcuts to useful pages (for example, a Confluence space or a runbook). In team-managed projects, the project admin turns features such as backlog, sprints, estimation, and reports on or off in project settings, and the sidebar changes to match. In company-managed projects, what appears depends on the project's type and boards, and admins can add shortcuts to the navigation.
Project Key Rules and Renaming
The project key is the prefix of every issue key (in ENG-402 , the key is ENG ). It appears in URLs, JQL, commit messages, and integrations.
Key Format Rules (Jira Cloud)
When you set or change a key, Atlassian requires that it:
- is at least two characters long;
- starts with an uppercase letter ; and
contains only uppercase letters or numbers .
What Happens When a Key Changes
Only organization, site, or Jira admins can change a project key, in Project settings > Details . When you change ALPHA to BETA :
Every issue is re-keyed. ALPHA-101 becomes BETA-101 , keeping the same number.
The old key is saved as a previous key. Atlassian stores previous keys so that links, filters, and queries using the old key continue to work . A browser request for /browse/ALPHA-101 opens BETA-101 .
Link aliases in text aren't rewritten. A description that mentions ALPHA-101 still says ALPHA-101 , but the link still opens the issue.
The old key is reserved. No new project can use ALPHA unless you delete it from the list of previous keys (or the project it belonged to is deleted).
You should still update saved queries. Atlassian recommends telling users about the change and updating board filters, dashboard gadgets, and other shared queries to the new key.
Deleting a Previous Key
Only organization, site, or Jira admins can delete a previous key, in the Previous project keys field of the project details. Deleting it frees the key for reuse, but anything still using the old key (links, board filters, dashboard gadgets, JQL) stops resolving. Warn users before you do it.
Project Categories: Organizational Taxonomy & Governance
A Project Category is an administrative grouping construct that allows organizations to organize multiple projects into logical business, functional, or regional portfolios (e.g., Core Banking , Mobile Applications , Internal Operations , EMEA Products ).
Administrative Configuration
Creating Categories : Requires the global Administer Jira permission (Jira settings, in the projects/spaces admin area).
Assigning Categories : A project can belong to at most one category. For company-managed projects, a Jira admin assigns it; in team-managed projects, the project admin can pick a category in Project settings > Details .
JQL Integration & Dynamic Filtering
Project categories excel at dynamic portfolio search. By categorizing projects, administrators and program managers can construct resilient filters and dashboard gadgets that automatically include future projects without modifying filter definitions: /* Retrieve all open critical defects across all banking systems */
category = 'Core Banking' AND issuetype = Bug AND priority = Critical AND resolution is EMPTY
- /* Exclude internal operational projects from compliance reporting */
- category != 'Internal Operations' AND created >= -30d
- /* Identify newly created projects that have not yet been categorized */
- category is EMPTY
When an administrator establishes a new project next month and assigns it to Core Banking , every saved filter, agile board, and dashboard gadget referencing category = 'Core Banking' immediately includes the new project's issues with zero query maintenance.
The Cardinal Security Rule of Project Categories
Caution
Project Categories Provide NO Security Boundaries. One of the most frequently tested concepts on the ACP-120 exam is the security behavior of project categories. A Project Category is purely a navigational and querying tag. It enforces zero access control, does not restrict issue visibility, does not grant permissions, and does not establish a multi-tenant boundary. Access to projects within a category remains governed strictly by the individual Permission Schemes and Issue Security Schemes bound to each project.