Skip to main content

Product Ideas Pipeline

Filter by Idea Status

Filter by Topic

1256 Ideas

Gunnar AndreasSeasoned ⭐️⭐️

Configuration of the default View in Search, and the order they appear in SearchNew

With the data modelling framework, most models will end up with a significant number of Views. Today we are not able to control the order the Views are presented in a good way. By reverse engineering it seems like the order of the Views is based on The order of the (first mentioned) CDM extension in the model definition. Alle non-CDM Views are listed at the end, irrespectively whether it is listed before CDM or not  What is considered a CDM extension by the UI is not based on the implements, but whether it reference at least one property from one of the CDM containers Inside each Category (eg, a specific CDM extension, or the non-CDM Views), the order in the model definition dictates the orderIf I choose alphabetic sorting it seems to only affect the non-CDM-Views, and not the order inside each CDM category. It do however put all the CDM categories first or last It is very inconvenient to use the order of appearance in the model definition as the way of sorting (we have to sort both the CDM extension, and then inside each category) since any change in the order will require pushing a new model definition to CDF.We need the ability to define the order it appears in the UI, independent of how it is listed in the model definition, and we need to be able to create groupings that do not follow the CDM extensions. Eg, we have maintenance information that are not a CogniteActivity extension, that we still want to group next to the other CogniteActivity extended maintenance information.The CDM based grouping is more relevant from a model developer point of view, and not that much from an end user point of view.We also need the ability to define what is the default View. Right now it seems to be the first View in the model definition that is a CogniteAsset extension.When changing location filer, it always reset to the (non-configurable) default, which we see create a lot of initial confusion with the users. Since the CDM Views are not explicitly described in our model, we do not see the CDM based grouping. 

Daniel Boechat De MarinsPractitioner ⭐️⭐️⭐️

Ability to Identify Deletions from PI-AF Source in CDFGathering Interest

Currently, the PI-AF Extractor works as a forward synchronization tool that reads the PI-AF structure and sends it to Cognite Data Fusion (CDF).The extractor correctly handles: Insertions: New elements created in PI-AF are detected and created in CDF. Modifications: Updates to elements or attributes (such as renaming elements or moving branches) are synchronized and reflected in CDF. However, when elements or branches are deleted in PI-AF, the corresponding objects remain in CDF, and there is no indicator that the element no longer exists in the source system. This behavior is currently intentional to prevent accidental or irreversible data loss in CDF.While this approach protects data in CDF, it creates challenges for downstream processes. Without any indication that an object was deleted in the source system, it becomes difficult to automate workflows that depend on identifying obsolete or removed elements.Requested capabilityA mechanism to identify when an element has been deleted from PI-AF, without necessarily deleting the corresponding object in CDF.For example, the extractor could mark such objects with a metadata field, tag, or status indicating that the element was removed from the source system.This would allow users to implement their own logic for handling these cases (e.g., archiving, cleaning up, or removing the objects in downstream processes) while maintaining the current protection against unintended data deletion.Use caseOrganizations that synchronize large PI-AF hierarchies to CDF often rely on automated pipelines and asset-based workflows. When assets or branches are removed from PI-AF, there is currently no straightforward way to detect this change in CDF, making it difficult to automate lifecycle management of these elements.Providing an indicator that an element was deleted in the source system would enable users to build controlled automation around these events. Regards Daniel

fredrik.thorkildsenCommitted ⭐️

Feature Request: First and Last Value Aggregates for Granularity-Based QueriesGathering Interest

Hello Cognite Support Team, I'm working with the Cognite Data Points API and would like to request a feature enhancement regarding aggregation functions. Current Situation: When querying time series data with a specific granularity (e.g., "1d" for daily), the available aggregates (Sum, Average, Count, Interpolation, StepInterpolation, etc.) don't directly provide the first or last actual data point within each granularity period. Feature Request: Could you add first and last aggregate functions that would:first: Return the earliest data point (by timestamp) within each granularity period last: Return the latest data point (by timestamp) within each granularity period  Use Case Example: For a time series with granularity: "1d" and aggregates: ["first"], the API would return the first recorded value for each day (e.g., the value at 00:00 or the earliest available timestamp that day). Similarly, aggregates: ["last"] would return the last recorded value for each day (e.g., the value at 23:00 or the latest available timestamp). Current Workaround: Currently, we're fetching hourly data (granularity: "1h") and then manually filtering/grouping to extract the first or last value per day, which is less efficient for large datasets. Question: Are there any plans to add native first and last aggregate functions? If this feature is already available through a different approach, I'd appreciate guidance on the best practice.