🔎 Subcomponents for Jira Cloud: component hierarchy on Jira issues

[#1]

Jira components are useful until the list gets long enough that the right component is hard to find, hard to explain, or hard to use consistently on an issue. The core idea behind Subcomponents for Jira Cloud is to keep Jira's native components, but organize them as a component hierarchy: admins can add existing or new components, group them with folders, and let users find issues for a whole hierarchy branch instead of only one flat component value.

In practice, that means users can browse components by product structure instead of guessing from a long flat list or memorizing naming conventions. They can choose a component in context, then keep the selected value connected to the Jira fields teams already use.

That helps when a Jira project has grown past a short, obvious component list: product modules, service areas, ownership boundaries, component versions, or release packages become easier to explain when users can see how the parts relate to each other.

Subcomponents for Jira Cloud also covers related component work: component versions, packages for modular releases, component and version properties, hierarchy export/import, project permissions, and REST API access.

Version 4.1.0 for Jira Cloud builds on that base by bringing the hierarchy closer to everyday Jira work: hierarchy-aware component and version selection on the issue form, tabbed navigation for the app's extension pages, and inline progress and breakdown bars in the hierarchy view.

🧩 Use the hierarchy on issue forms

The main 4.1.0 change is that users can apply the subcomponents hierarchy at the moment they create or edit Jira issues: select the right component from the tree, avoid guessing from a flat field, and assign component versions in the same issue-form workflow.

Two custom fields make this possible:

• Components (Subcomponents app) - opens the hierarchy picker where you can browse and select components in context. Use the dropdown to pick from a flat list, or click Add from hierarchy to select from the tree.

• Versions (Subcomponents app) - shows component versions grouped by component for Fix versions, Affects versions, and other version fields. Click Add from component versions to open the picker.

For existing issues, users can also open the Subcomponents picker from the issue actions menu. For issue creation, the custom fields on the issue layout are the recommended path.

There is one setup step to remember: the app creates these fields, but a Jira administrator still needs to add them to the relevant Create/Edit issue screens. Once configured, the selected values sync back to Jira's native fields. On create, Jira's native fields are populated after the work item is created. On edit, they update immediately. Existing native values are kept and combined with the selected values.

That means the hierarchy picker improves how users choose components and versions without replacing the Jira fields teams already report on.

🧭 Move between app extensions from one page

Hierarchy work often touches more than one app surface. Teams may need to move between Subcomponents, Component versions, Packages, Component properties, and Version properties.

In 4.1.0, those app extensions are available from a single tabbed page, so users can switch between the listed surfaces in one place.

This is a navigation change, but it matters because hierarchy work is rarely isolated. A user may start with the component tree, check related component versions, open packages, then review component or version properties. Keeping those surfaces together makes the workflow easier to scan and explain, especially for admins onboarding users to a structured component setup.

📊 Scan progress before opening Jira search

The third part of the release adds inline bars to hierarchy items.

For Subcomponents, the bar shows a breakdown by issue type, with counts and percentages in the tooltip. For Component versions and Packages, the bar shows progress by work item status, so users can see how close a version or package is to completion.

The tooltip also includes View all issues in Jira search, which opens the matching issues in Jira search. That keeps the workflow simple: scan the hierarchy, spot the branch or package worth checking, then jump to the issues behind it.

The release makes that issue-search path more visible in the hierarchy view itself.

Worth a look

If your Jira components and versions have outgrown flat lists, Subcomponents for Jira Cloud is worth evaluating in a sandbox. Start with the hierarchy itself: whether it makes components easier to choose, explain, and search. Version 4.1.0 then adds a practical layer on top: users can pick from that hierarchy, navigate the related app surfaces, and open the matching Jira issues with less context switching.

---

From the Broken Build team behind Subcomponents for Jira Cloud