Feature ideas

Summary: Enable the creation of aggregation properties on a blueprint even when there is no direct relation path to the target blueprint. This would allow, for example, tracking DORA metrics at the organization level without requiring explicit relationships from the organization blueprint to all relevant lower-level entities (e.g., services, incidents, deployments). Background & Motivation: Currently, Port requires an explicit relation path between the source and target blueprints for aggregation properties to function. This limitation prevents users from aggregating metrics at higher organizational levels (such as the org or company level) unless all necessary relationships are modeled in the data structure. Executives and leadership teams often need to see organization-wide metrics (such as overall DORA metrics), but the current model only supports aggregation where direct or indirect relations exist between blueprints. This is a significant gap for organizations seeking holistic visibility and reporting DORA Metrics Guide. Request: Allow aggregation properties to be defined on a blueprint even if there is no direct or indirect relation path to the target blueprint. Alternatively, provide a mechanism to define "virtual" or "global" aggregations that can operate across the entire catalog, not just along existing relation paths. This would enable organization-level rollups for key metrics (such as DORA) without requiring complex or artificial relationship modeling. Impact: This feature would enable executive-level reporting and organization-wide metric tracking, addressing a common requirement for leadership dashboards and strategic decision-making.

I have several properties that are reused across blueprints (for example with enums and colors). I have tried making those blueprints, but you lose functionality, and the relationships created just do not make sense. I have reverted to just copying the work across blueprints. It would be nice to have reusable "controls" within a blueprint. Similar thought for self-service actions.

Mapping relations using search queries always returns an empty result when you use the Test Mapping selection. We request that rather than an empty array, the actual result for the mapping be displayed.

Currently, relating blueprints and their entities to one another can be done with ease using jq in the data source mapping. While this is helpful, it would be beneficial if Port could auto-discover and propose relations between certain things.

Some data models include blueprints such as CI/CD jobs or deployments. These blueprints usually get filled with high number of entities, but the entities in these blueprints become stale and lose relevancy very quickly. With this feature, users will be able to configure custom retention for specific blueprints, giving them the option to automatically delete old entities once the number of entities for the blueprint passes X entities, or if an entity was updated more than 1 week/month/year ago

When checking a property on blueprint as file existence e.g my_workflow: file://.github/workflows/my.yml it would be useful to offer multiple file extensions without the need to maintain multiple properties e.g. my_workflow: file://.github/workflows/my.yml my_workflow: file://.github/workflows/my.yaml This would save some false positives on scorecards where file extensions differ

We need to have the ability to restore data in case somebody deletes a property with data by accident

Today a relation can be only for one blueprint, but this FR suggests having a relation that is modeled to be one of multiple blueprints. For example - "Resource" blueprint can be connected to one of - service, cloud resource, or on-prem resource, so we create this special relation, and for each entity the relation can be one of the connected blueprints. For mirror properties, you will be able to mirror only the common properties (meta properties, and intersecting ones)

When fetching a property of an entity in self service form field, it is fetched once and doesn't recalculate and fetch the new entity's property when selection is changed in the form. for example Entity 1 is selected in a form, then its property is displayed in the next field. If entity 2 is selected, the property field is not updated with the property of entity 2.

The IaC options currently do not allow for management of READ permissions on entities (all other permissions for blueprints appear present). In our use case, we would like to deny READ permission access to the private feedback we will have our teams submit using a self-service action. Unfortunately, we cannot roll this change out through IaC, it is going to have to be done manually in the UI. Its awkard and will certainly bite us in the future not to have READ permissions source controlled with the rest of the permissions.