Merge or “Consolidate” Extended Relations in Collection Views and Boards

[B_Sp]

Another great feature of Fibery are the powerful, multi-directional Lookups. I frequently use these to “extend” deep across multi-level Relations, to get to the same entity that can be related directly to another entity, but also be visible through an extended LookUp many levels and directions away.

One thing I’ve found is that I when I create these set ups, I get the relation showing up from the particular connection in many “Collections.” Here’s what I mean:

In the Fibery Product Team Template, we have a Product Area that can relate to both a Feature and a Story. However, a Story is also a child to a Feature. If we want to see on the Product Area’s Collections the Stories that are not directly related, but are part of a Feature, we have to set up a LookUp from Features. This will be called something like “Features’ Stories.” However, we have another Collections area showing the directly related Stories. So in the end, we have two sets of Story Collections, but in reality all those Stories are “connected” to the Product Area.

So I think it would be great if we could consolidate when we create extended connections to the same Type, without having multiple Collections that are in isolation from each other, even though they are about the same Type.

This would also be very helpful in Boards, because as I understand it, the common Type would be available as a Row or Column. So in this example, you could make a board with “Tasks” as the Entity represented, and “Product Area” as a row. And then you could see all Tasks associated with the Product Area, including those not directly related but part of Features.

Thanks and hope that’s clear!

[Chr1sG]

I understand the need you’re describing, but I think it’s worth noting that on some occasions the distinction between the two relations is important, and it is not desirable to aggregate them. For that reason, if ‘consolidation’ was available, then it needs to be optional.

[B_Sp]

Chris, 100% yes. I should have actually mentioned that, so thanks for adding. No question I would like to have both cases:

• Where I can show distinct instances of the a relation or Lookup to the same Type

• Where I could consolidate into one “aggregate” collection of Entities out of the Type that is related in multiple ways - directly, via Lookups.

Thanks again!

[B_Sp]

I wanted to point this out again. Curious if power users such as @Oshyan or @Matt_Blais or anybody else has seen this need as the Fibery instance grows…

Let me add another way this is useful: I have a few hierarchical set ups in Fibery that go 3 + levels down:

project → Phase → task → Subtask

Epic → Story → Dev Task → Subtask

Division → Department → Branch

On the lower levels, I’d like to see what top level item they relate to.

Examples:

What Project is a task in

What Epic is a Dev Task in

I can get that information with lookups. However, I wind up with two fields to deal with. The direct relation, and the lookup. What I can’t do is focus on the top-level and see all the lower levels inside it, this is what I was trying to describe here:

@B_Sp

This would also be very helpful in Boards, because as I understand it, the common Type would be available as a Row or Column. So in this example, you could make a board with “Tasks” as the Entity represented, and “Product Area” as a row. And then you could see all Tasks associated with the Product Area, including those not directly related but part of Features.

So now if I want to see at the bottom level what sub-tasks are in, I have to make a lookup to the 2nd level - Project Phase, but I also need a lookup from Project Phase to see what project the Sub-task is in. This can get cumbersome if I’m in a meeting, looking at the subtask, and nobody can see what project it’s in, even if we created a lookup to the 2nd level of Project Phase. We have to make sure to create a host of lookups, none of which can be merged.

As @Chr1sG suggests, this could be an optional feature as there might be a need to keep those lookups. Either way, it would be EXTREMELY useful. Right now I am continuing to add, reluctantly, a myriad of lookups across hierarchies that go more than 3 deep because that’s the only way at a glance to see “up” the hierarchy. I feel like this is a feature that would really enhance Fibery given the great capability we have with lookups. It would refine the capability and make it more user friendly and digestible, and I think provide yet another feature not found anywhere among competitors.

Thanks guys!

[mdubakov]

It seems your problem can be solved via hierarchical lists, just add such list into your top level entity.
For example, here I have hierarchy
Product Area → Feature → Bug and can see it all inside a Product Area

[YvetteLans]

I think I have the same problem as @B_Sp.

So I have the following set-up

• Areas → Persoonlijke groei (= personal growth)
• Sub area -(self relation Area) Trainingen (= courses)
• Tasks within that sub area (for example "Training copywriting = copywriting course)
• Notes within that task (to write down my course notes)

So if create a note within the task ‘Copywriting course’ that note does not have the area ‘Persoonlijke groei’ or sub area ‘Trainingen’.

Only the task has a relation with Area trainingen.

@mdubakov that note will also not show in a hierarchical list. You see below that ‘Trainingen’ does not cointain notes.

It’s only visible via a look up. And it’s not possible to show the main area (‘Persoonlijke groei’)

[B_Sp]

Yes thank you @YvetteLans , that is right! What I’m talking about is when you have multiple levels and would like to see consolidated the relations as one “collection” (the original name of the view within an entity of entities that are related many - to - one to that entity.

The hierarchical list @mdubakov is pointing out is a good way to view this, but it doesn’t allow a way to see within an entity the consolidation of the lower-level relations to that entity.

Hoping that’s clear and we can get this into the development backlog soon!

[B_Sp]

Wanted to point out that this remains a big need and a way to limit duplicating of information. @YvetteLans appreciate the support and hoping you still have the need as well, need all the supporters on this that are out there!

[YvetteLans]

We do have the need as well. In the meantime we’ve created workarounds. But it makes the workspace heavier than it should be.

[B_Sp]

Great thanks for the support Yvette!