Skip to main content
Gathering Interest

Enhance Tree View visualization for views extending from CogniteAsset

Related products:Search and Data Exploration
  • August 4, 2025
  • 2 replies
  • 120 views

Juliano.Marinho
Practitioner

With the use of Cognite Core Datamodel, we can create different types of Assets. 
Right now I have a case where I have EquipmentTag and Functional Locations.
An EquipmentTag always has a FLOC a parent. 
So the Hierarchy is always:

FLOC1
-- FLOC1.1
----EquipmentTag
FLOC2
--EquipmentTag

In this case, If I open the EquipmentTag, te UI is trying to get all the hirarchy as EquipmentTag, so the UI knows that exists a path, but can’t create the tree-view cause no data is returned. 
If I open the same EquipmentTag just as an Asset, the tree-view works fine, but then I lose all the specific data from my EquipmentTag.

Openning as EquipmentTag

 

2 replies

Darren Downtain
Practitioner

I view this not as a product enhancement but rather as a defect in the current implementation that doesn’t allow for mixed hierarchies.  We have several projects that have multiple subtypes of CogniteAssets defined and a separation of FunctionalLocation(Area) and EquipmentTag are part of our recommended model for asset centric industries so this has a high level of visibility for clients currently being converted as well as the majority of our quick start motions.


Sofie Svartdal Berge
Seasoned Practitioner

Hi ​@Juliano.Marinho !

I understand the pain point, and this is high on my priority list. 

I wanted to share some background around the current implementation: 

Our implementation in Search is today focused on one view (“Category”) at a time, which is why a Tree view with path/hierarchy traversing views/categories is not currently supported. Over the last 6 months, we have seen new patterns in Data Modeling across customers, and the need for supporting path/hierarchy between instances of different views/categories. 

We are in the process of determining how we technically should support a Tree view with a path/hierarchy between instances of different views/categories, including how to handle which view to open an instance through when interacting with such a Tree view. 

A couple of the challenges are around

  1. On the main search page, the instances presented (including the count) are per view/category. With a Tree view that includes instances from other views/categories, this count would not be correct, or would need adjusting. We have some thoughts on design here. 
  1. On both the main search page, but also on the instance details page (as you show in your screenshot), a Tree view that includes instances from different views/categories leads to some challenges around which view/category to direct the user when interacting with instances in the Tree view. When modeling “subtypes”/extensions of Asset, we typically see the same instance represented through multiple views, and we need to ensure the user is directed to the view that makes the most sense. We have some thoughts here as well, and are currently experimenting. 

We need to ensure that the way we handle path/hierarchy between instances of different views/categories is robust, and this requires quite a bit of testing on our end.

Thank you for your patience, and will keep you updated when we have progressed on this. 

Best, 

Sofie, Product Manager