Long text, bear with me, I think this is a cool thing although it requires some backend rewriting (and ofc frontend too).

So, imagine having Project X (a big project) which of course will have to be split into a bunch of activities. In order to track these activities today in Favro, you would typically do this by any of these three flavours:

A. Create a Kanban board named "Project X", create some columns acting as states of the activities and then you would create cards as activities placed in these various states/columns.

or

B. You would create a backlog/list named "Project X", create a bunch of cards in the list and then add a "Status" column to the list in order to track the activity status.

or

C. A combination of A and B. First create B. Then create A without the cards. The cards/activities then would be dragged/added from the backlog to the Kanban board. And the backlog would add a column called "Relation" showing the card relation/status. That way you have split the process into two views with slightly different focus. The one on the left being the "Overview" and the one on the right being "Where shit happens".

So far so good and I guess a lot of users are familiar with this outstanding feature in Favro allowing data to be in more than one place at a time (no more copying stuff).

The problem with the A and B approach is that it's only one view. No real abstraction has occurred and that typically is what you want in order to streamline your processes.

The problem with C, is that whenever you create a card, either to the left or right, you need to explicitly connect that card to the other view by "adding" the card (drag n drop typically).

By introducing Containers this extra work wouldn't be needed (one of many benefits).

Here's how containers would work:

First of all, the concept of cards would have to be changed.

Any current backlog, board or card should be able to act as a container. And any container should be able to contain other containers. Container is the new work item and can be of the type: card, list, kanban, chart, etc. Further, the same container can exist in multiple places in the same collection offering different ways of looking at the same data (not possible today in Favro).

Referring to the example C above, but done with the idea of containers:

Let's suppose we are working in collection "Cool". Create a new container with the type "kanban". Name it Project X. Define some status columns.

Now create containers of type "card" inside Project X. Place them in various columns/states. This so far is the same as route A above.

Now, choose to "Add existing container" to the same collection "Cool". Select "Project X". Now change the view type to "list".

This is identical to route B above but with the cards already created because we simply add an existing container with the items in it.

Moving "cards" around in Project X (kanban style) would then immediately reflect in the "list" view of the same container.

Immediately we can see that adding a card in any of these two views (list or kanban) the link is explicit without having to connect a card to another backlog/board, because it is in fact the same container.

Now, already improved on Favro we can do a lot more with this.

You can for example list multiple containers inside a container to follow the workflows of multiple kanban boards.

This also beautifully solves the problem many of us have addressed, namely that of allowing a card to have sub cards (infinitely) keeping the relation to the parent card explicit.

I have pretty clear ideas on how the UX would have to adapt to accommodate this idea of containers.

I understand this is not something that will be implemented in the now, but I strongly believe this is a solution that will solve other issues where there are semi awkward workarounds like linking cards and boards using attachments, etc.

Couple this with custom work flow rules operating on any of the container fields (custom or not), this will be next level Favro.