Kanban Routes: Automate Work Hand-offs Across Teams, Programs and Portfolios

Work rarely stays with one team from beginning to end. A product manager approves an idea. A product owner refines it. An architect reviews it. A release train plans it. A delivery team implements it.

The work may move through several boards, but the handoffs between those boards are often handled through chat messages, email, meetings or manual copying.

Kanban Routes make those handoffs part of the process.

You define a simple rule:

The card is not copied. It remains the same Jira issue or Azure DevOps work item while becoming visible on the boards that need to work with it.

A route connects boards through Handoffs.

When a card reaches the configured Source Column, Kendis places it on the Destination Board in the configured Destination Column.

If that destination column has another handoff, the card can continue to the next board.

A route summary uses a simple format such as:

4 boards · 3 handoffs

These two capabilities work together but solve different problems.

You can open the designer from several places:

When you open the designer from board settings, Kendis checks for unsaved changes first so the board structure and the route configuration do not become inconsistent.

The designer opens on the Kanban Routes listing.

This page gives you a searchable overview of the routes you can access.

For each route, you can see:

Use the route menu to:

Select Create Route to start a new route.

Open a route to enter the visual designer.

The designer has three main areas.

The Board Library lets you search boards across the collections you can access.

Boards already connected to the route are marked as On canvas.

Select a board to inspect its structure and then add it to the canvas.

Each board appears as a card showing its columns and sub-columns.

To create a handoff:

Kendis draws the connection between the two columns.

Return paths are displayed differently so it is easy to distinguish them from the main direction of flow.

You can also select columns and use Hand off to column instead of drawing the connection manually.

Select a handoff to edit its details.

You can:

A clear label such as Approved for refinement or Ready for architecture makes the route easier to understand as process documentation.

Routes can be reviewed in two ways.

Use the canvas when you want to understand the overall process visually.

Use List view when you want to review connected columns in a more compact, auditable format.

List view is especially useful for larger routes that span several collections.

Here is a practical example.

Open Kanban Route Designer and select Create Route.

Give the route a name that describes the process, for example: Idea to Delivery

Open the Board Library and add the boards that participate in the process.

The boards can come from different collections, subject to route rules and permissions.

Place the boards from left to right in the order work normally moves.

Use Tidy up if you want Kendis to reorganise the layout automatically.

For example:

Add a short label that explains what the handoff represents.

Check the board and handoff counts, then use Canvas or List view to verify the connections.

Autosave is enabled by default. You can also switch it off and save manually.

Once the handoff has been saved, it is active.

You do not need to keep the Route Designer open for the handoff to work.

When a card arrives in a connected source column, Kendis:

The destination team sees the card arrive without anyone copying it manually.

The card is not duplicated.

It remains the same Jira issue or Azure DevOps work item while appearing on the boards that need to work with it.

A handoff can feed another handoff.

For example: Product Management → Product Owner → Architecture

If the destination column on the Product Owner board also sends work onward, one move on the first board can carry the item through the route.

A handoff is not limited to drag and drop.

It can also fire when a card arrives in the source column because its field value changed elsewhere.

For example, if a column is mapped to a Jira Status and the issue moves into that status through Jira, the Backlog or the Kendis card, the handoff can be triggered.

This makes Kanban Routes work with the underlying process, not just with manual board interaction.

Cards arriving through a route stay on the destination board until they are explicitly removed, even if they later fall outside that board's normal scope.

Routes are validated so that only workable handoffs are saved.

Kendis refuses a connection that would allow a card to travel in a circle indefinitely.

Return paths are allowed when they do not close a loop.

A board cannot hand work to another column on itself through Kanban Routes.

Use normal board movement or mapping for movement inside one board.

Both sides of a handoff must be compatible with the same underlying Jira or Azure DevOps account.

A handoff between incompatible ALM connections is refused rather than being saved in a broken state.

The same handoff cannot be created twice.

Creating, editing or removing handoffs requires the appropriate manage access.

Users without edit rights can still review routes in view-only mode.

Every board has a Handoffs tab in its settings.

For that board, you can see:

Which boards and columns send work into this board.

Where each connected column sends work next.

You can edit or remove a handoff directly from the board settings, or open the Route Designer when you need to see the full process.

A column that receives work through a route can also show the handoff in its mapping badge.

Routes become especially powerful when the source and destination columns also have field mappings.

Imagine this flow:

One move can therefore update the ALM, hand the item to the next board and place it into the correct planning context.

If the destination mapping does not match the arriving card, Kendis does not force the value. The card waits in the funnel so the receiving team stays in control.

Users without manage rights see the designer in view-only mode.

An approved portfolio item moves into the Release Train's intake, and accepted work can continue to team-level boards.

This is useful when planning responsibilities are distributed across several layers.

A Product Owner sends an item to Product Management when it is ready for review.

A return path can send it back when more input is needed, provided that the connection does not create a circular loop.

Accepted customer requests move from an intake board into a delivery board without anyone re-keying the work.

A support item reaching Escalated to engineering can appear automatically in Engineering Triage.

A few practices make routes easier to operate over time:

Imagine an insurance organisation running Jira.

The company creates a route called Idea to Delivery.

It connects three boards:

A product manager moves Digital First Notice of Loss into Approved.

The same Jira issue appears on the Product Owner board at the top of Ready for refinement.

Later, the Product Owner moves it to Needs architecture, and it appears in the architects' Intake.

If the architects need more information, a valid return path can send it back to Needs input on the Product Owner board.

Nothing was copied. The same work item moved through the process while each team worked from its own board.

No. The same item becomes visible on the boards it reaches.

No. Handoffs continue to work after they are saved.

Yes, when the route requirements are satisfied, including the ALM requirement.

Yes.

Yes. A return path is allowed when it does not create a circular loop.

Yes, when the change causes the card to arrive in a mapped source column.

Up to 200.

Mappings and handoffs attached to the replaced columns are removed. Review the Handoffs tab and recreate any connections that are still needed.