5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes

Standard vs. Sub-task Issue Types & Issue Type Schemes

Issue types form the foundational classification system in Jira Cloud. Every piece of work tracked in Jira—whether a software defect, user story, strategic initiative, or operational maintenance task—is instantiated as a specific issue type. How an issue type is configured dictates which fields it displays, which screens it invokes, which workflow it executes, and how it rolls up into portfolio-level reporting.

For enterprise Jira administrators preparing for the ACP-120 exam, mastering issue types requires more than knowing how to create a new type. You must understand the structural mechanics separating standard issues from sub-tasks, the multi-tier hierarchy model, how Issue Type Schemes scope configurations across company-managed projects, and how to safely execute issue type migrations without data loss.

---

Standard vs. Sub-task Issue Types: Core Architecture

Jira Cloud categorizes all issue types into two distinct categories: Standard Issue Types and Sub-task Issue Types. This binary distinction is established at the moment of issue type creation and cannot be directly toggled via a simple checkbox afterwards.

+-------------------------------------------------------------+
|                       Standard Issue                        |
|                   (Story, Task, Bug, Epic)                  |
|  - Has independent lifecycle and security level             |
|  - Can link to other issues via issue links                 |
+-------------------------------------------------------------+
                               |
              +----------------+----------------+
              |                                 |
              v                                 v
+---------------------------+     +---------------------------+
|         Sub-task          |     |         Sub-task          |
|  - Bound to parent        |     |  - Bound to parent        |
|  - Inherits project &     |     |  - Inherits project &     |
|    security level         |     |    security level         |
|  - CANNOT have sub-tasks  |     |  - CANNOT have sub-tasks  |
+---------------------------+     +---------------------------+

Critical Sub-task Constraints

Administrators frequently encounter edge-case scenarios on the ACP-120 exam regarding sub-task behavior:

1. Security Inheritance: A sub-task takes its project, issue security level, and sprint from its parent. It can't have a different security level, and when the parent's level changes, the sub-tasks follow.
2. Project Movement: Moving a parent issue to another project via Move Issue will migrate all attached sub-tasks into the target project. Conversely, moving an individual sub-task to another project requires converting it into a standard issue first, or moving it to a different parent within the target project.
3. Conversion Lifecycle: Standard issues can be converted to sub-tasks (provided a valid parent issue is designated), and sub-tasks can be converted to standard issues. Both operations use the Convert to Sub-task or Convert to Issue actions from the issue's action menu, which launches a guided conversion wizard to reconcile mismatched workflow statuses and required fields.

---

The Jira Cloud Issue Hierarchy

In modern Jira Cloud, the issue hierarchy extends beyond the historical three-level model (Sub-task -> Standard -> Epic). In Jira Cloud Premium and Enterprise tiers, organizations can construct unlimited custom hierarchy levels above Epics using Advanced Roadmaps (Plans).

[!NOTE] In Jira Cloud's modern architecture, the historical Epic Link custom field has been unified into the standard Parent field. The Parent field is now the universal hierarchy mechanism: a Sub-task points to its Story via Parent, a Story points to its Epic via Parent, and an Epic points to its Initiative via Parent.

---

Issue Type Schemes: Purpose and Configuration

An Issue Type Scheme acts as an administrative filter between the global pool of all created issue types and individual company-managed projects. Without issue type schemes, every project in a Jira instance would be forced to display every issue type created by any team.

Administrative UI Path

• Global Management: Cog (Settings) > Issues > Issue type schemes
• Project View: Project settings > Issue types (displays the currently applied scheme)

Scheme Capabilities

When configuring an Issue Type Scheme (Edit Issue Type Scheme), an administrator controls three distinct parameters:

1. Available Issue Types: Dragging issue types between the Available Issue Types column and the Issue Types for Current Scheme column defines exactly which types users can create inside associated projects.
2. Default Issue Type: Specifies which issue type is pre-selected when a user opens the Create dialog in an associated project. If no default is set, Jira falls back to its own choice (commonly the type the user last selected).
3. Display Order: The vertical drag-and-drop order in the Issue Types for Current Scheme box determines the order in which issue types appear in the dropdown selector of the issue creation interface.

The Default Issue Type Scheme

Every Jira Cloud instance includes a system-generated Default Issue Type Scheme. Any newly created company-managed project that is not explicitly assigned a custom scheme is automatically bound to this default scheme.

[!WARNING] Modifying the system Default Issue Type Scheme alters the available issue types for every unassigned project across the entire Jira instance. Enterprise administrators should leave the default scheme intact and create dedicated, reusable custom schemes (e.g., "Software Standard Scheme", "Business Operations Scheme") for production projects.

---

The Issue Type Migration Wizard

One of the most heavily tested operational procedures on the ACP-120 exam is modifying an active Issue Type Scheme to remove an issue type that is currently in use by existing issues.

When an administrator edits an Issue Type Scheme and removes an issue type (for example, removing Bug from a project that currently contains 45 active bugs), Jira will not silently delete or hide those issues. Doing so would violate relational data integrity. Instead, Jira detects the orphaned issues and immediately halts the save operation, launching the multi-step Issue Type Migration Wizard.

+-------------------------------------------------------------+
|                Issue Type Migration Workflow                |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
| Step 1: Impact Assessment & Target Type Selection           |
| - Identifies affected projects and counts of orphan issues  |
| - Administrator selects a replacement Issue Type per project|
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
| Step 2: Workflow & Status Mapping                           |
| - If target issue type uses a different workflow, Jira      |
|   requires mapping each old status to a valid new status    |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
| Step 3: Field Value & Configuration Reconciliation          |
| - Prompts for default values if the target issue type has   |
|   Required fields that were previously unset or missing     |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
| Step 4: Confirmation & Asynchronous Indexing Task           |
| - Jira updates database records and re-indexes all affected |
|   issues in the background without instance downtime        |
+-------------------------------------------------------------+

Step-by-Step Migration Mechanics

1. Step 1: Target Issue Type Selection: Jira presents a breakdown of affected projects and the count of orphaned issues. The administrator must select a valid replacement issue type from the scheme's remaining types (e.g., remapping all Bug issues to Task).
2. Step 2: Status Reconciliation: If the target issue type is mapped to a different workflow scheme or workflow than the source issue type, the wizard analyzes whether the existing issues reside in statuses absent from the target workflow. The administrator must map every orphan status to a valid target status in the destination workflow.
3. Step 3: Field Value Reconciliation: If the target issue type's Field Configuration requires fields that were optional or not present on the original issue type, the administrator must provide valid values for those required fields during the wizard execution.
4. Step 4: Asynchronous Processing: Upon confirmation, Jira runs a background re-indexing and migration job. Search indexing updates automatically, and all issue keys remain unchanged (e.g., PROJ-101 remains PROJ-101, but its type changes from Bug to Task).

---

Governance Best Practices: Mitigating Scheme Sprawl

A common administrative anti-pattern in growing organizations is creating a new issue type for every request submitted by team leads (e.g., creating separate issue types for "Frontend Bug", "Backend Bug", "Security Defect", and "UI Polish"). This causes extreme scheme sprawl, clutters JQL searches, complicates dashboard gadgets, and requires maintaining dozens of redundant workflows and screen schemes.

When evaluating a request for a new issue type, certified administrators apply the following decision framework:

• Do these issues follow a fundamentally different lifecycle? If yes -> New Issue Type (requires distinct workflow).
• Do these issues require radically different mandatory fields or screens? If yes -> New Issue Type (requires distinct field configuration/screen scheme).
• Do these issues simply represent a sub-category or functional domain? If yes -> Do NOT create an issue type. Use a single issue type (Bug) and capture the distinction using a Component (e.g., Frontend, Backend), a custom Single Select field, or Labels.

---

Blueprint 3.1 Details: Renaming, Sub-tasks, Time Tracking, Epics, and Team-Managed Types

Impact of Renaming an Issue Type

Issue types in company-managed projects are global objects. Renaming one (for example, Defect to Bug) changes the name in every project and scheme that uses it. Existing issues keep their type because Jira stores the type's ID, not its name. Check saved filters, board filters, automation rules, and integrations that refer to the old name as text, and update any that break.

When to Use Sub-tasks

Use sub-tasks when one piece of work must be split among several people or tracked in small steps, but still reported as a single deliverable. For example, a story might have Design, Build, and Test sub-tasks. Remember the constraints:

• Sub-tasks can't have their own sub-tasks.
• Sub-tasks sit under standard issues. Jira's UI doesn't let you create a sub-task directly under an epic.
• Sub-tasks live in the parent's project and inherit its security level and sprint.
• A Sub-task Blocking rule on the parent's workflow can stop the parent closing until its sub-tasks reach chosen statuses.

How Time Tracking Rolls Up to the Parent

When time tracking is enabled, each sub-task has its own Original estimate, Time spent, and Remaining estimate. The parent issue's time-tracking display shows roll-up totals that combine the parent's own values with those of all its sub-tasks. Logging work on a sub-task doesn't change the parent's own fields. The roll-up is calculated for display and reporting. If totals look wrong, check whether work was logged on the parent, on the sub-tasks, or on both.

Epics, Including Cross-Project Epics

An epic groups standard issues (stories, tasks, bugs) through the Parent field. In company-managed projects, the parent epic doesn't have to be in the same project. A story in project B can have an epic from project A as its parent, provided the user can browse both projects. This is the usual pattern for a program-level epic that spans several team projects. Boards that include both projects then show the epic alongside its children. Team-managed projects keep their epics and child issues within the project.

Creating Issue Types in Team-Managed Projects

In a team-managed project, the project admin creates and edits issue types in Project settings > Issue types (Work types), with no Jira admin involved. Each team-managed issue type has its own field layout, and team-managed projects can use different workflows for different issue types. These issue types belong to that project only. They don't appear in, or affect, any company-managed issue type scheme.