The Core Idea: One Rule, Many Rows
Think of the assignment mode as a classification function. Given a work item, it answers the question: “which bucket does this belong in?” Each unique bucket becomes a swimlane row. When a work item is dragged from one swimlane to another, Planningboard does not just move a visual tile — it actually writes back to Polarion, updating the underlying field (assignee, parent link, enum value, or SAFe team reference) that the mode is based on. This write-back behavior is what makes Planningboard more than a read-only view. The swimlane you drop a card into becomes the new value of the assignment field for that work item.
Available Assignment Modes
TheassignmentMode widget parameter accepts one of the following values. Each is described below.
Users (Assignee) (ASSIGNEE)
Each swimlane row represents one user who holds a specified role in the project. The board reads the project’s role assignments to determine which users appear as rows, then places each work item under the row matching its assignee.
How rows are populated: Planningboard queries the project’s User Management for all users holding the configured User Role (for example, project_user). Only users with that role get a swimlane. If you later add a user to that role, a new row appears on the board automatically.
What the drag-drop writes back: When you drag a card to a different user’s swimlane, Planningboard updates the work item’s assignee field in Polarion to that user.
Key limitation — multiple assignees: When a work item has more than one assignee, it currently appears under only one swimlane, not under all assigned users’ rows. Users expecting the card to be duplicated across all assignees’ lanes will not see that behavior. This is a known product limitation, with an enhancement tracked to display items under all assignees in a future release.
Filtering by Team (optional): If the Teams Service is enabled (useTeamsService = true), the Users (Assignee) mode can filter swimlane users to members of a specific team rather than all role-holders project-wide. This requires coordinating two settings: the Team page parameter (which filters swimlane rows) and a Plans query (which filters iterations to the same team). Configuring only one of them leads to a mismatch where swimlanes filter but iterations do not, or vice versa.
Filtering by Plan range (optional): Starting with version 25.12.0, you can enable nextedy.planningboard.activeTeamAssignmentsInPlanRangeOnly=true in Polarion Configuration Properties. When enabled, users whose Team Assignments fall entirely outside the date range of the currently displayed Plans are hidden. Work items still assigned to those users move to the “Not Assigned/Other” row. This keeps the board focused on active capacity only.
Parent Item (PARENT)
Each swimlane row represents one parent work item. Child items appear under the row of their parent. This mode is ideal for seeing task distribution across features, epics, or other hierarchical groupings — for example, checking how tasks break down under each user story in a sprint.
How rows are populated: The parent items are discovered via a Lucene query (the Parent Query parameter) and optionally filtered by a link role (the Parent Role parameter, for example implements). Only work items matching the parent query appear as swimlane rows. The parentWorkItemType property can further restrict parents to a specific type.
What the drag-drop writes back: Unlike other modes, when you drag a card to a parent’s swimlane, Planningboard does not let you place it under an unrelated parent. Because the card’s parent relationship is structural data, the system enforces the correct parent automatically — if you drop a card in the wrong row, it snaps back to the row its actual parent occupies. Swimlane assignment here is derived from the existing link structure, not freely chosen.
Sorting: Planningboard supports sorting parent swimlanes by any custom property, including priority (available since version 25.9.0). The Sort By parameter controls the vertical order of parent rows.
Important constraint — normalization: The Parent Item mode does not support plan normalization (planCellsMode). If you need capacity normalization across Plans, use a different assignment mode.
Enumeration Field (ENUM)
Each swimlane row represents one value from a chosen enumeration custom field (for example, a team field with values Frontend, Backend, QA). This mode works with both single-value and multi-value enum fields.
How rows are populated: Planningboard reads all available option values of the configured enum field (enumFieldId) and creates one row per value. You can restrict which values appear as rows using the Rows Filter parameter — selecting a subset of enum values means only those values produce swimlane rows.
What the drag-drop writes back: Dragging a card to a different row updates the enum field on the work item in Polarion to the value that row represents.
Multi-value enum fields: When the field allows multiple values and a work item carries more than one, it can appear in multiple swimlane rows simultaneously, one row per value it holds. This is the key behavioral difference from other modes.
Field type restrictions: Not all enum-typed fields are valid. The status, resolution, and type system fields are not supported for swimlane grouping with this mode. Use a custom enumeration field.
Enum field options are configured per work item type in Polarion. If you change the work item type filter on the board, the available enum values in the rows filter change accordingly — the filter reflects only the options defined for the currently selected type.
Project (PROJECT)
Each swimlane row represents one sub-project within the current project group. This mode is designed for cross-project planning — useful for portfolio and program boards where work spans multiple Polarion projects.
How rows are populated: Planningboard discovers all sub-projects readable by the current user within the project group, then creates one row per sub-project. The current project itself is excluded from the row list (to avoid double-counting). Projects the user cannot read are also excluded silently.
What the drag-drop writes back: Moving a card between project swimlanes reassigns the work item to the target project in Polarion.
Limitations: No additional filter parameters are available for the Project mode (beyond the optional Report Link). All readable sub-projects appear.
SAFe Assignment Types
Three assignment modes are designed specifically for SAFe (Scaled Agile Framework) environments. They require a Polarion SAFe Solution configuration to be in place:
Program / Solution Teams (SAFe) (
SAFE_TEAM) — swimlane rows are the SAFe teams active in the current program, sourced from Polarion SAFe Solution data. Dragging a card updates the safeTeamField custom field on the work item. The default custom field ID is safeTeam.
Agile Release Train Teams (SAFe) (SAFE_TRAIN_TEAM) — similar to Program / Solution Teams (SAFe) (SAFE_TEAM), but restricted to teams belonging to a specific ART (specified via the ART ID parameter). Useful for ART-level sprint boards.
Programs (SAFe) (SAFE_PROGRAMS) — swimlane rows are SAFe programs within a solution train. This is for portfolio-level planning. Uses the safeProgramField custom field (default ID: safeProgram).
If your organization uses SAFe and you want to enable these swimlane options, contact Nextedy support for setup guidance. SAFe assignment modes depend on the Polarion SAFe Solution extension being correctly configured in your instance.
No Swimlanes (NONE)
This mode disables swimlane grouping entirely. All cards appear in a single undivided board area without row separation. The board still has Plans as columns, but there is no horizontal grouping of rows.
When this makes sense: For high-level planning or quick overviews where the volume of items is manageable and team-based or hierarchy-based partitioning would add complexity rather than clarity. Also appropriate when capacity tracking per resource is not needed.
Shared Behaviors Across Modes
Empty Swimlanes
By default (showEmptySwimlanes = false), swimlane rows with no work items assigned are hidden. Setting showEmptySwimlanes = true forces all possible rows to appear even if empty. This is useful when you want to see the full set of team members or enum values on the board, regardless of current workload.
Collapsible Swimlanes
All modes support collapsing individual swimlane rows (collapsibleSwimlanes = true by default). Users can collapse rows they are not currently working with to reduce visual noise on dense boards.
Swimlane Sort Order
TheswimlaneSort parameter controls the vertical ordering of rows. The default value is alphabetical. For the Parent Item mode, custom sorting by properties like priority is supported (see the Parent Item section above). Note that the swimlane sort order and the item sort order within each lane are coupled — changing one can affect the other.
The “Not Assigned / Other” Row
When a work item does not match any defined swimlane row — for example, it has no assignee, its parent is not in the parent query, or its enum field is empty — it falls into an overflow row typically labeled “Not Assigned” or “Other”. This row is always present unless the board has no such items.Choosing the Right Mode
The table below summarizes the primary use case for each mode:Common Misconceptions
“I can place a card under any parent swimlane.” Not with Parent Item mode — the row a card belongs to is determined by its actual parent link in Polarion. Dropping it in the wrong parent’s row causes it to snap back to its real parent’s row. To change the parent, update the link in Polarion, not by dragging on the board. “Swimlanes and columns are the same thing.” Swimlanes are horizontal rows; columns are Plans (time-based). The assignment mode controls rows only. Plan display is governed separately byplansMode — see Plans Modes.
“An item with two assignees appears in both assignee swimlanes.” Currently it does not. Multi-assignee items appear in only one swimlane. See the Users (Assignee) section above for details on this known limitation.
“Any enum field can be used for the Enumeration Field mode.” System fields status, resolution, and type are not supported. Use a custom enumeration field.
Related Concepts
- Board Structure — how Plans (columns) and swimlanes (rows) combine into the full board layout
- Plans Modes — the equivalent concept governing column (Plan) organization
- Capacity Tracking — how capacity bars relate to swimlane rows
- SAFe Integration — deeper context for the SAFe assignment modes
- Teams Service — how the Teams Service integrates with the Users (Assignee) mode for team-filtered swimlanes