Bug vs Subtask in Jira Cloud: Choose the Right Defect Structure

A tester finds a missing checkout validation message while a story is still awaiting acceptance. Another test exposes a duplicate charge in a previously released purchase flow. Both are defects, but they need different handling: the first may be a bounded correction within one story, while the second needs independent triage and regression verification.

Choose a standard Bug when the finding needs an independent lifecycle, then link it to the work that supplies context. Choose an available native subtask when the correction belongs to one standard parent's acceptance and the team can manage it within that boundary. This is a decision policy for your team, not a Jira rule that automatically prioritizes findings or closes their parents.

Compare Lifecycle Before Choosing the Type

Begin with the scope and disposition of the finding rather than the screen where someone discovered it. A standard Bug is a useful representation when the team must prioritize the defect separately, consider it for another release, investigate a regression, or coordinate work across several stories. Links preserve those story relationships without making one story the Bug's native parent.

A parent-bound subtask suits a narrower situation: one open standard work item needs a specific correction before acceptance. Subtasks can be assigned and tracked individually, so the correction owner and the person verifying the result need not be the same. The parent relationship expresses work breakdown; it does not replace a clear description of the failed requirement.

Apply the same criteria to either option. Who decides priority? Who owns the correction and verification? Can the finding remain open independently of the story's acceptance? Which release discussion must include it? Will the team's defect report include the chosen type? A team that answers only the parentage question can still lose the finding from its review process.

Prefer a linked standard Bug for independent disposition. This keeps a cross-story or released regression out of an artificially narrow acceptance task. For a bounded correction, a native child is reasonable only when the appropriate child type is available and the team's acceptance policy supports that arrangement. If configuration is unclear, preserve the finding and refer the structural question to triage instead of assuming an administrator will change Jira.

Respect Jira's Native Parent Boundary

In Jira's documented default software hierarchy, Bug, Story and Task are standard work types at the same level. Subtask is below them and cannot have native children. A Story can therefore contain a subtask, and a standard Bug can contain subtasks, but a standard Bug is not a subtask merely because it concerns a Story.

This also answers the request to put a Bug under an existing Subtask. A link can associate the Bug with that Subtask, but the association does not create a native grandchild. Keep the existing child key as discovery context and identify the wider Story or Bug context when it helps reviewers understand the finding.

Work item links have relationship descriptions, such as an inward and outward description for a dependency. Linking must be enabled, and users need the Link Work Items permission. Do not assume a displayed relationship is available to every user or that a Blocks link enforces a workflow transition. The association and any enforced workflow condition are separate concerns.

A link-based or Marketplace view may arrange related items visually. Before relying on that display, establish what it represents and which underlying field or link owns the relationship. A tree on a screen is insufficient evidence that Jira's native parent boundary has changed. No particular app capability is needed for the choices described here.

Jira Premium and Enterprise support additional hierarchy levels, but the documented creation procedure adds new levels at the top. It does not provide a new native level underneath Subtask. Changing hierarchy is also a broader administrative decision, not a routine response to an individual QA finding.

Check the Management Model Before Using Sub-bug

A proposed child called Sub-bug needs more scrutiny than its name. Company-managed and team-managed spaces offer different work-type configuration. Confirm the management model and the actual type category before choosing a representation.

Company-Managed: A Separate Configured Child Type

In company-managed spaces, a Jira administrator with Administer Jira permission can create a work type in either the standard or sub-task category. Work-type schemes associate those types with the relevant spaces. Specialized subtask types are therefore possible, subject to the actual configuration.

Sub-bug is an illustrative name for such a configured child type. It is not a default Jira software type, and it does not mean the existing standard Bug has been renamed or moved below Story. The child type must belong to the subtask category, subtasks must be enabled, and the relevant scheme must make that type available.

Ask the administrator to confirm those prerequisites before making Sub-bug part of a working agreement. Editing a name, description or avatar is different from establishing the correct type category. This comparison does not require a new type, a scheme change or conversion of existing work.

Team-Managed: Use the Suggested Subtask

Atlassian's current team-managed documentation states that custom work types can only be standard types; custom parent and subtask types cannot be created. The suggested Subtask is the documented native child option beneath standard Stories, Bugs and Tasks.

Creating a custom standard type named Sub-bug does not supply the missing child category. Likewise, the documented ability to edit a type's name, icon, description, fields or workflow should not be read as permission to create a new custom subtask category. Use the suggested Subtask where it fits, and describe the defect correction clearly within it.

Team-managed type administration also has its own administrator role and Administer spaces permission prerequisites. Availability in the documentation does not establish that a particular tester has those permissions or that a tenant exposes the assumed setup. Keep the structural recommendation separate from any later authorized configuration work.

Apply the Choice to a Checkout Finding

Consider the fictional, unexecuted input packet CHECKOUT-DEFECT-STRUCTURE-1.0. It defines four requirements: R1 needs a checkout validation message; R2 prohibits duplicate charging after a retry across checkout and saved-card purchases; R3 requires an auditable failure reference; R4 requires a tax explanation on the receipt.

In this scenario, Story CHK-410 is in QA for checkout work, while CHK-420 is in QA for the receipt explanation. CHK-430 represents previously released saved-card work. An existing Subtask, CHK-411, belongs to CHK-410 and covers retry error handling. The scenario assumes one company-managed configuration with an available Sub-bug child type, a team-managed alternative using the suggested Subtask, and a configuration with no available child type.

The table applies the same policy to each finding: independent release, regression or cross-story scope favors a linked standard Bug; a bounded acceptance correction may use an available native child. Responsibilities are proposals, not accepted assignments. None of these items or changes has been created in Jira.

Finding in Packet 1.0	Recommended Structure	Proposed Responsibility	Acceptance or Follow-Up
F1: Missing validation message, R1	Sub-bug child of CHK-410, company-managed configuration only	Checkout developer fixes; Checkout QA verifies	Keep R1 open until the message is verified
F2: Same R1 gap, team-managed variant	Suggested Subtask child of CHK-410	Checkout developer fixes; Checkout QA verifies	Same R1 acceptance check; no custom child type
F3: Duplicate charge regression, R2	Standard Bug; link CHK-410 and CHK-430	Payments owner coordinates; Regression QA verifies	Prioritize independently and review both story contexts
F4: Missing failure reference while testing CHK-411, R3	Standard Bug; link CHK-411 and CHK-410	Checkout developer fixes; Checkout QA verifies	No child beneath CHK-411; retain the R3 failure evidence
F5: R1 correction, no available child type	Standard Bug; link CHK-410	Triage lead resolves structure; Checkout QA verifies	Preserve the finding without changing configuration
F6: Deferred receipt correction, R4	Standard Bug; link CHK-420	Product owner decides scope; Receipt QA verifies	Record any approved deferral; do not imply R4 has passed

F1 and F2 are alternative configurations of the same validation gap, not instructions to create duplicate findings. Each remains tied to the R1 acceptance check. The company-managed variant uses the assumed configured Sub-bug; the team-managed variant uses its suggested Subtask.

F3 requires attention beyond CHK-410 because R2 also concerns released saved-card work. Linking CHK-430 preserves that context while the standard Bug receives its own triage decision. Calling the finding a child of the open checkout Story would not adequately express the scenario's independent regression responsibility.

F4 demonstrates why discovery location should not determine parentage. The missing failure reference was observed while testing CHK-411, but CHK-411 cannot parent another native child. The proposed Bug links to both CHK-411 and CHK-410. This preserves discovery and requirement context without expanding the existing Subtask's accepted scope or inventing a new hierarchy level.

F5 uses a standard Bug because the scenario has no available child type. Preserving the finding is more important than waiting for an assumed configuration change. F6 uses a standard Bug for a proposed later-release correction, but that representation does not approve postponement. R4 still requires an explicit scope decision; an open linked Bug is not evidence that the original receipt criterion passed.

Preserve Verification and Reporting Across Either Choice

The work type does not make the defect reproducible or establish that the fix works. For either a standard Bug or child-represented correction, agree on a compact evidence record:

• The requirement, reproduction conditions, and expected versus observed behavior.
• The affected build or environment, relevant Story or Subtask keys, and evidence location.
• The proposed correction owner, verification owner, and next triage decision.
• The retest result and any remaining regression scope or acceptance exception.

These are recommended review contents, not a claim that every Jira tenant has a matching field. Record impact and severity using the team's configured fields or agreed description convention. Do not assume a universal built-in Severity field or equate severity with Priority: Jira documents Priority as relative importance, which administrators can customize.

Status and Resolution also need separate attention. Status records the work item's place in its workflow; Resolution describes how work was completed. A team's QA verification policy should identify what evidence permits the relevant transition and how unresolved findings affect acceptance. The names and available transitions depend on configuration.

Parent acceptance needs an explicit rule. Company-managed workflows can use a Subtask Blocking Condition on selected transitions, but a child relationship alone does not establish that the parent is blocked or will close automatically. A linked standard Bug likewise does not automatically change a Story's status. Review the actual workflow and the acceptance decision instead of reading either relationship as a guaranteed gate.

Reporting requires the same care. A filter selecting only the standard Bug type will not, by that selection alone, include findings represented as another child type. Before relying on a defect total, check the intended population, configured filters and the treatment of Subtask or custom Sub-bug work. This is a review of report definitions, not a measured claim that one representation loses more defects.

Board visibility is also configuration-dependent. For example, team-managed documentation describes grouping by Subtask to view children on a board. Do not infer that every board or release report exposes all findings in the same way. Have the intended reviewer confirm that the chosen representation is visible where the team makes its acceptance and release decisions.

Make a Bounded Triage Decision

Use a short review before asking anyone to change structure:

1. Decide whether the finding needs independent triage, release planning or regression ownership, or remains a bounded correction for one open standard parent.
2. Confirm the actual management model, available type category and linking permissions. Escalate unavailable configuration rather than assuming a new child type can be created.
3. Identify the requirement and discovery context, then propose correction and verification responsibilities. Keep an existing Subtask as context when it cannot be a parent.
4. Check acceptance, reporting and release implications before treating the representation as agreed. Record any approved deferral separately from a verification result.

Choose the representation that preserves the finding's lifecycle and review responsibility. Use a linked standard Bug when the defect must stand independently; use an available native child when the correction genuinely belongs inside one parent's acceptance. If those conditions are unclear, retain the evidence and resolve the uncertainty through triage before making structural changes.