Combined Mapping for Columns and Swimlanes
CLOUD DATACENTER
Topics
Introduction
We support 2 use cases for Combined Mapping outlined below:
when multiple values for the same fields could be assigned to Columns/Swimlanes
when a secondary field (mapping) could be introduced
Both should provide ultimate possibilities to craft your board your way.
Columns/Swimlanes with multiple values assigned
In most of the cases we allow a single value of Jira field as column/swimlane. So when users move the issue into the column/swimlane it’s straightforward to resolve and assign values.
If you need multiple values → use Column Groups.
But sometimes you do want to have an option to assign multiple values. In such a case you have 2 challenges:
what to show in column/swimlane - issues that has all values assigned? or at least one?
To address this we have the following configuration in board settings:
what to do when user moves issue into column/swimlane - try to assign all the values? or play smart and see what can you assign?
For the later see use cases below.
Multiple Statuses
You can assign multiple statuses for columns/swimlanes. OR configuration in settings needs to be turned ON to allow such assignment.
Since the issue can’t sit with 2 statuses only one could be assigned. When you will be moving issue into such a column/swimlane the App will analyse the workflows of the projects attached to the board and specific project for the issue and shortlist the possible statuses from the ones assigned to column/swimlane.
If the candidate is “One Only“ the App will assign appropriate status on move. If there are couple of available options the App will show a dialog to select.
Multiple Versions, Components, Labels and other multi-select fields
This is a good use case for cross-project components and versions when different teams develop in different Jira projects but have a unified set of versions and components.
In Jira versions and components are tied to projects so in case you want to emulate the use case mentioned above you create duplicates of versions, components in all the projects assigned.
Now let’s say you brought issues from those projects to out board and you want to use mapping to assign version/component. So you create columns/swimlanes and map “avatars“ for proper cross-project version/component to it.
In the past we would deny move to such Column/Swimlane (for obvious reasons). But with recent functionality release the App will check the project key for the issue and assign only appropriate version/component.
Enjoy it!
Append values on move vs override
If OR configuration is on for the multi-values columns/swimlanes (but statuses) you can decide if you want to append you new value when you move (keeping the old ones) or override (removing the old ones).
Secondary Mapping for Columns and Swimlanes
ADVANCED FEATURE
An alternative approach to combined mapping is using a secondary field or value for column or swimlane definitions. This allows you to set a primary field and then fine-tune it with a secondary one—unlocking powerful flexibility to shape the board your way.
Here’re couple of use cases as example that will be elaborated below:
Better Release Planning by combining Releases (Product Increments) with Sprints planning
Splitting Teams into functions (if required for better planning)
The rest of the app’s functionality remains unchanged—only the way columns and swimlanes are defined is different. When a work item is moved into a specific cell via drag and drop, both the primary and secondary field mappings will be applied to the item.
Doing-Done Kanban Model (or new statuses w/o Admin Access)
In many organizations, workflows are standardized, and adding or modifying statuses requires admin involvement and approvals. This can limit teams' ability to innovate—for example, experimenting with new statuses or introducing more granular ones to improve visibility and flow efficiency.
With Advanced Kanban & Agile Boards, you can overcome this limitation by using a secondary field (such as a label or custom field) alongside the primary status field.
For example, you can configure a Doing–Done Kanban model for both the requirements preparation and development phases. This gives you better visibility into where delays occur, helping you optimize your delivery flow.
Go to Board Settings > Column & Swimlane Configuration
Select Labels for e.g. as secondary field (could be also custom field or any other variation that suits your need). Click Back to the Boards.
If you selected auto creation of the columns you can now jump and edit it to fine tune. Otherwise, you might create new ones.
For our example we will create Doing-Done variations of statuses where it matters and group them into status-groups
Now we can move items into specific columns and better visualize the flow and use all the App functionality to spot delays and improve efficiency.
Under the hood, the app will assign the appropriate status and label (if configured) to any work item moved into a specific column. Any changes made to these values outside the app—whether in Jira or other apps—will be automatically reflected on the board.
Once the approach proves to be effective, you may consider requesting a workflow change at the organizational level to adopt a more efficient and optimized process—or simply continue using the secondary mapping within your team.
Better Release Planning by combining Releases (Product Increments) with Sprints planning
In most cases, modern releases span multiple sprints—either within a single team or across several teams by nature of the work involved.
As a result, effective release planning requires not only assigning work items to a specific release but also understanding in which sprint each item will be delivered. This becomes especially important for managing dependencies—for example, when deliverables from Team A in Sprint A are needed by Team B in Sprint B as part of Release 1.2.3.
Let’s explore how Advanced Kanban & Agile Boards, and specifically the Secondary Mapping feature, can help configure such a setup.
Go to Board Settings > Column & Swimlane Configuration
Setup Fix Version as Primary field and Sprint as Secondary one.
If you selected auto creation of the columns you can now jump and edit it to fine tune. Otherwise, you might create new ones.
Suggestion is to create column groups by Releases to aggregate sprints as Columns.
Now, by moving an item into a specific column, you’ll automatically assign a Fix Version to plan it for a specific release and place it into the appropriate sprint for the right team. You can also easily reassign it later using drag and drop.
Splitting Teams into functions (if required for better planning)
We all appreciate cross-functional teams that can deliver work end-to-end without relying on other parts of the organization.
However, this often means bringing together complementary—but not interchangeable—functions within the same team. For example, a team might include a DBA, a DevOps engineer, or separate frontend and backend developers instead of full-stack engineers.
In such cases, it’s helpful to visualize work not only at the team level but also by specific function within the team. This helps identify bottlenecks and optimize flow more effectively.
At scale, it's common practice to use the Team field as a swimlane. We suggest enhancing this by using a secondary field (e.g., Labels or Custom Fields) to break it down further—by Team/Function—for more granular visibility.
More use cases
There are, of course, many more possible use cases. If you need guidance or support, feel free to reach out to the contacts listed below. We'd also love to learn from your use case—please don’t hesitate to share it with us.