> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Board Structure
> Nextedy PLANNINGBOARD organises Polarion Plans and work items into a two-dimensional grid that makes planning capacity visible at a glance.
## The Two-Dimensional Grid
Think of the board as a spreadsheet where **columns represent time** (Plans) and **rows represent ownership or scope** (swimlanes). Every cell at a column–row intersection is a planning slot. When you drag a card into a cell, you are simultaneously saying *when* the work is scheduled (the Plan column) and *who or what owns it* (the swimlane row).
This is distinct from a simple Kanban board, where columns represent workflow states. On Planningboard, columns represent Polarion Plans — iterations, sprints, program increments — not status values. Status progression happens inside Polarion as usual; the board's job is to answer "what is planned in which sprint, for which team member?"
## Columns: Plans
Each column on the board corresponds to one Polarion **Plan** (a sprint, iteration, program increment, or custom planning period). The Plans shown are determined by the **Plan query** configured in the widget parameters, together with two count parameters: `lastPlans` (default `1`) controls how many past or completed Plans are visible, and `nextPlans` (default `5`) controls how many upcoming Plans are shown. This windowing approach keeps the board focused on the near-horizon without showing an overwhelming history.
The `plansMode` widget parameter determines which kind of Plan objects are used as columns — for example, **Project Plans** (`PROJECT_PLANS`) or SAFe Program Increments. Changing `plansMode` changes which configuration options are available for Plans, which is why the widget configuration UI looks different depending on the mode selected.
A common first-time misconception is that columns represent work item statuses (To Do → In Progress → Done). They do not. Columns are Polarion Plan artifacts — time-boxed planning containers. Moving a card between columns re-assigns it to a different Plan; it does not change the work item's status field.
## Rows: Swimlanes
Swimlanes divide the board horizontally. Each swimlane represents a grouping of work items sharing a common attribute — an assignee, a parent work item, a project, or a custom enumeration field value. The **swimlane assignment type** (`assignmentMode`) determines which attribute drives the grouping.
The available assignment modes are:
| Assignment mode | What each row represents |
| ----------------- | -------------------------------------------------------------------------------- |
| Users (Assignee) | Each team member assigned to the project via a specified user role |
| Parent Item | Each parent work item (e.g. feature, epic) linked to child tasks |
| Enumeration Field | Each value of a custom enumeration field (e.g. Team, Priority) |
| Project | Each Polarion project, for cross-project planning |
| SAFe types | SAFe Programs, Program Teams, or Agile Release Train Teams (requires SAFe setup) |
| No Swimlanes | All items appear in a single unified row |
### The Not Assigned/Other Row
When a swimlane assignment mode is active, items that have no value for the grouping attribute appear in a special **Not Assigned/Other** row (`UNASSIGNED`). This row is not just a display location — it is also a drag-drop target. Dragging a card from a user swimlane to the Not Assigned/Other row removes that specific user from the work item's field, which is particularly relevant for multi-valued fields where an item can appear in more than one swimlane simultaneously.
### Multi-value Swimlane Appearance
When the grouping field supports multiple values (for example, a multi-user assignee field or a multi-enum custom field), a single work item can appear in more than one swimlane row at the same time. Each appearance represents one of the item's values. This means the same card can be visible in Alice's row and Bob's row if both are assigned. Dragging from one of those rows to the Not Assigned/Other row removes only that row's value, leaving the other assignments intact.
### Swimlane Sort Order
The `swimlaneSort` property (default `alphabetical`) controls the vertical order of rows. For the **Parent Item** assignment mode, sort order can be configured by custom properties such as priority — a capability added in Planningboard 25.9.0. Note that the swimlane sort order is coupled to the item sort order within each swimlane; there is currently no independent sort control for items within a lane versus the lane itself.
When you change the swimlane sort order, the ordering of work items within each swimlane changes in tandem. This is a known limitation — independent sort controls are not available in the current version.
## Cards: Work Items
Each **card** on the board represents a single Polarion work item. The card's position in the grid encodes two pieces of planning information simultaneously: which Plan it belongs to (column) and which swimlane group it belongs to (row).
Card content is customizable through widget parameters, but the fundamental planning semantics — column = Plan, row = swimlane grouping — are fixed by the board's structural model.
Clicking a card opens the **Work Item Properties** sidebar, which shows configurable fields and allows in-context edits without leaving the board. The board preserves your swimlane and scroll position when you save sidebar changes, so you can work through a list of cards without losing your place on large boards.
When hovering over a card, three quick actions become available: **Show Links** (highlights linked cards and hides all others), **Add Link** (creates a link to another card), and **Unplan item** (moves the card back to the Unplanned section).
Cards with the work item status **Verified** cannot be moved or unplanned once placed. This is an intentional lock to protect verified work from accidental replanning.
## The Unplanned Section
The Unplanned section on the right side of the board is a backlog panel — a holding area for all work items that have not yet been assigned to any Plan. It is the starting point for the primary board interaction: drag a card from the Unplanned section onto a Plan column and swimlane row to schedule it.
The Unplanned section can be filtered by assignee, team, or predefined queries to help surface the right cards for the planning session. It can also be toggled off using the **Show Unplanned** toolbar button when you want to focus entirely on the board grid.
## Capacity Bars
Each cell at the intersection of a Plan column and a swimlane row can show a **capacity bar** — a visual indicator of how much capacity is consumed versus available for that swimlane within that Plan. Capacity bars require explicit configuration through widget parameters.
Hovering over a capacity bar shows a detailed tooltip with per-user capacity data, including allocated capacity (sum of remaining estimates for assigned work items), total capacity (from the team calendar), and available capacity (the difference). Negative available capacity signals overallocation.
Capacity data is calculated server-side and embedded in the board when the page loads. Users whose team calendar has no entries default to a total capacity of 0.0.
Capacity bars do not appear by default. They are enabled through widget parameters for capacity loading (`capacityLoad`, `userCapacityLoad`, `capacityField`). See the [Capacity Tracking](/planningboard/concepts/capacity-tracking) concept page for how capacity calculation works.
## Toolbar Controls
The toolbar in the upper-left corner of the board provides board-wide controls that complement the structural layout:
| Control | Effect |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Collapse / Expand all | Folds or unfolds all swimlane rows at once (individual rows can also be toggled by clicking them directly) |
| Refresh data | Reloads board data from Polarion without a full page reload |
| Toggle Resource Load | Shows or hides the capacity bars across all swimlanes |
| Show Unplanned | Toggles the visibility of the Unplanned section |
| Prioritize | Enables the Prioritization mode for ordering items within swimlanes |
| Show Dependencies | Reveals all dependency links between cards across the entire board (requires dependency link roles to be configured in widget parameters) |
The **Show Dependencies** toolbar action is distinct from the **Show Links** card-level action. Show Links highlights only the links of the single card you hover; Show Dependencies reveals all dependency connections across the board simultaneously.
## How the Structure Fits Together
The structural model of Planningboard can be summarised as a deliberate mapping from Polarion concepts to spatial positions:
This mapping is what makes drag-and-drop on the board meaningful: placing a card at a specific (column, row) intersection updates the work item's `plannedIn` Plan in Polarion and, depending on the assignment mode, may also update the field used for swimlane grouping (such as the assignee field).
## Common Misconceptions
**"Moving a card changes its status."** It does not. Column position reflects Plan assignment, not workflow state. Status is a separate Polarion field edited through the sidebar or Polarion itself.
**"Swimlane rows are always assignees."** The assignment mode is configurable. Rows can represent parent work items, projects, enumeration field values, or SAFe structural roles — not just users.
**"The capacity bar shows story points remaining."** The capacity bar represents capacity consumed relative to available capacity, derived from team calendar data and the `capacityField` you configure. The unit depends on your configuration (hours, story points, or another numeric field).
**"All work items in the project appear on the board."** The work item dataset is filtered by the `query` widget parameter and capped at `maxItems` (default `1000`). Items outside the query result are not visible even if they exist in Polarion.
## Related Concepts
To understand the individual structural elements in depth, see:
* [Swimlane Assignment Modes](/planningboard/concepts/assignment-modes) — how each assignment type works and when to choose it
* [Plans Modes](/planningboard/concepts/plans-modes) — how Plan columns are generated for different planning methodologies
* [Capacity Tracking](/planningboard/concepts/capacity-tracking) — how capacity is calculated and displayed in each cell
* [Normalization](/planningboard/concepts/normalization) — how capacity figures are normalised across swimlanes with different team sizes
* [Prioritization](/planningboard/concepts/prioritization) — how item ordering within swimlanes works
For practical setup, see [Create Your First Planningboard](/planningboard/getting-started/first-planning-board) and [Basic Board Interactions](/planningboard/getting-started/basic-interactions).
**KB Articles**
* Introduction to Planningboard
* Planningboard interface & basic interactions
* Swimlane Assignment Types
**Support Tickets**
* [#6681](https://support.nextedy.com/helpdesk/tickets/6681)
* [#5879](https://support.nextedy.com/helpdesk/tickets/5879)
* [#6509](https://support.nextedy.com/helpdesk/tickets/6509)
**Source Code**
* `AssignmentMode.java`
* `Config.java`
* `enum-rows-filter.cy.ts`
* `PlanningBoardWidget.java`
* `enum-rows-filter-folder-scope.cy.ts`