Feature ideas

Today, aggregation properties can take up to 15 minutes to update after new integration data is ingested. During onboarding and ongoing configuration, this can leave dashboards and widgets temporarily empty or outdated even though the underlying data has already synced. An on-demand resync would provide faster feedback and make dashboard setup and validation more reliable.

Request: Allow users to trigger an on-demand recalculation of aggregation properties after integration data has been ingested. Current behavior: Aggregation properties can take up to 15 minutes to recalculate after new integration data is synced. Problem: Dashboards and widgets may remain empty even though the underlying data has already been ingested. This creates confusion and makes it difficult for users to confirm that their setup is working correctly. Expected outcome: Users can initiate a resync of aggregation properties without waiting for the scheduled recalculation cycle. Once complete, dashboards and widgets should reflect the latest data.

It could happen that the aggregation property cannot be made because of the limitation on the number of entities to aggregate. I would like to be able to go further with this limitation. It could be made with some drawbacks such as a worse freshness in the calculation (example: 1 minute if less than 500 entities, 10 minutes for less than 5000, ...)

The Relations Graph currently renders connections between entities and blueprints without showing relation labels (e.g. Contains, Deploys to, Authenticates via) alongside the directional arrow. Users who need to understand not just that two nodes are connected but how, the semantics and direction, have no way to read this from the graph without clicking into individual entities.

The current layout places blueprint groups that have no relations to the rest of the graph directly in the middle of connected subgraphs, making complex data models harder to read. Users are forced to manually drag disconnected components out of the way each session, with no persistence. Automatically detecting and rendering disconnected components as spatially isolated clusters would dramatically improve readability of large or multi-domain data models.

Sometimes customers have a complex data model with many blueprints and the default view has many overlapping blueprints and relations which can be confusing. Customers can move the blueprints around in the UI to make the data model look less chaotic, but they don't persist in the UI after you log out. Customers would like this to be the case so the view is less chaotic.

Statement: A Service Account is related to a Bucket. Question: How are they related? Answer: The Service Account (entity SA1) has Read/Write/Delete access to Bucket (entity B1). How Do We Know: This data is available during syncs/ingestion, and could be "placed" on the relation for each edge.

We have 1 kind mapped to two blueprints. So the AWS integration fetches EC2 instances twice: -once for aws-resource blueprint -and once for infrastructure asset blueprint

Add the ability to mirror a property from a related blueprint even, regardless of the direction of the relation.

When defining an aggregate property, we're able to specify both: pathFilter which controls which entities are included in your aggregation calculation based on their relationship path from the source entity query which is applied to all entities on the target blueprint I'm proposing an enhancement whereby we can specify a JQ filter ( query -like) which is applied to a mid-path blueprint on a multi-hop relation. For example: Blueprints: _team --owns-> service --involved_in-> incident Aggregation: (on _team ) which counts the total incidents for the last 90d, across all service s they own. As with all metrics, this is to highlight potential problem areas the team may want to invest time in. Now lets say our service blueprint included a status property - an enum of Active / Decommissioned . Allowing us to retain the valuable data we've collected on any service after it's been torn down. This also acts as a lever for filtering in/out such service entities. We could have the aggregate count all incidents across all services. But what's the point in the team investing time on a service we've already decommissioned? We'd rather have the aggregate filter out any service entity with status=Decommissioned , and then count all related incident entities. Workaround you could mirror the status value onto the incident blueprint, and then use pathFilter + query . However this only works if the (direction of) relationships can support the mirror property. It's not always viable. Those using Terraform are potentially more restricted: https://roadmap.port.io/ideas/p/terraform-pulumi-add-relation-resource