4.2 Project Templates, Project Keys & Project Categories

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.

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:

1. Every issue is re-keyed. ALPHA-101 becomes BETA-101, keeping the same number.
2. 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.
3. Link aliases in text aren't rewritten. A description that mentions ALPHA-101 still says ALPHA-101, but the link still opens the issue.
4. 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).
5. 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.