Board problem with subtasks

[Dominik Architek]

Hi Community,

We have a reproducible issue on a company-managed Scrum board (new board experience) where sub-tasks that meet every board criterion do not render on the sprint board.

Environment
- Jira Cloud, new board experience
- Company-managed Software project (key: SOS)
- Scrum board, grouped by Stories
- Board filter (JQL): project = "SOSiR Wewnętrzny" AND labels in (E1, Portal)
- Example parent story: SOS-71, in the active sprint "SOSIR_FR Sprint 1"
- Example sub-tasks: SOS-233

Expected behavior
With the board grouped by Stories, the sub-tasks of SOS-71 should appear as cards under their parent's swimlane, in the mapped "To Do" column.

Actual behavior
Only the aggregate parent card is shown. The sub-tasks do not render, and the parent story is not promoted to its own swimlane.

Verification (common causes already ruled out)
The sub-tasks meet all board criteria:
- Board filter: SOS-233 carry the labels E1/Portal and ARE returned by the exact board-filter JQL in the issue navigator.
- Sprint: their Sprint field is set to "SOSIR_FR Sprint 1" (same as the parent).
- Parent: their Parent field correctly points to SOS-71.
- Status: their status ("To Do") is mapped to a board column.
- No quick filters are active.
- The user reproducing this has board-admin permissions.

Key symptom (suggests an index/rendering inconsistency)
- Performing a trivial bulk edit on the sub-tasks (touching any field) makes them appear on the board.
- After a simple browser page refresh, they disappear again.
- This is fully reproducible.

[Germán Morales]

Hi @Dominik Architek ,

The missing piece is likely ranking. The board filter you posted does not end with ORDER BY Rank ASC, and Atlassian documents that ranking is also what enables Jira to group subtasks underneath their parent work item.

Open Board settings and select Add Rank, or update the filter to:

project = "SOSIR Wewnętrzny" AND labels in (E1, Portal) ORDER BY Rank ASC

With swimlanes based on Stories, Jira should then create one swimlane for SOS-71 and place its matching subtasks underneath it. See Atlassian's documentation for enabling ranking and Stories swimlanes.

If the problem remains after Rank is enabled, confirm that SOS-71 itself is returned by the board filter, not only SOS-233. If both the parent and its subtasks match and they still disappear after a refresh, that suggests a board rendering issue rather than a configuration problem.

[Dominik Architek]

Unfortunately the problem still persists

I added rank to filter:

project = "SOSiR Wewnętrzny" and labels in (E1, Portal) ORDER BY Rank ASC

The subtasks and stories are returned from filter.  And again, when i touch subtask for example change status for a moment the story is in swimlane but after refresh subtask dissapear from the board.

[Germán Morales]

Thanks, that rules out Rank as the cause. Before treating this as a rendering bug, check the board’s per-user view state: open View settings → Swimlanes → Expand all Swimlanes.

Collapsed swimlanes hide the work items beneath each parent, and Jira reapplies view settings for each user after a refresh. That would fit the subtasks appearing immediately after an edit and disappearing again when the board reloads. Atlassian documents this in the board and backlog view settings.

If Expand all Swimlanes is already selected, temporarily change Group by to No swimlanes and refresh. If the subtasks remain visible there but disappear again when grouped by Stories, that isolates the problem to Stories grouping rather than the filter or Rank.

[Dominik Architek]

Changeing group by and expand all doesn`t make any effect. Just "touch" subtask changeing view for a moment

[Arkadiusz Wroblewski]

Hello and Welcome to Atlassian Community @Dominik Architek ,

There is a related unresolved issue, JRACLOUD-98264, involving the board UI not consistently re-evaluating subtasks after filtering and changing the grouping. Its exact behavior is different, so I would not claim that it is the same defect, but it indicates that this part of the new board experience has known refresh inconsistencies.

At this stage, I recommend having Atlassian Support investigate the board data returned during a full refresh.

Community members cannot inspect the board’s hierarchy response or your site’s rollout configuration, which is now what is required to determine why the subtask is removed during the full board reload.

Best,

Arek🤠