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.

We'd like for developers to be able to define arbitrary thresholds for scorecard “badges” colors, so they could get their color dynamically changed based on the value they hold. For example, when the number of vulnerabilities is rising, the color would swap to “scarier” options (green -> red). Users might have different reasons and conditions for color-coding their scorecards, and leaving the threshold setup up to the customizers might be easier.

Enable condition rules using property paths (e.g., related entities) to support contextual queries. This functionality is currently unsupported and requires a workaround using mirror properties.

There is a limit on the number of Wiz Issues pages that can be processed by the integration. https://github.com/port-labs/ocean/blob/main/integrations/wiz/wiz/constants.py PAGE_SIZE = 100 MAX_PAGES = 500 We would benefit if the this values can be configurable via a selector in the integration config.

We would like the ability to add tooltips (property description) for scorecard property column headers in scorecard-specific dashboard widgets, matching the functionality available for regular blueprint properties. You can add descriptions to scorecard rules in the blueprint, but they don't appear in the charts.

Currently, users cannot be added to an existing SSO-managed teams in Port until they log in, even if they already belong to the team in the SSO provider. This creates a gap where team assignments aren’t visible in Port until the first login, preventing admins from ensuring that team data is complete before users start using Port.

We need the ability to pause and resume data source syncs. While we understand that rate limits determine the sync frequency, having the option to pause and resume would give us control over the order in which data sources sync. This capability is essential as we gradually roll out Port to different teams, ensuring their service data is accurately captured and reviewed before proceeding to the next team.

I’d like to propose a feature that would prevent users from progressing to the next stage or submitting a form based on specific conditions. Right now, we’re relying on hidden required fields to enforce this, which is bug-prone and limited. Implementing it similar to “Step-level visibility”[ https://docs.port.io/actions-and-automations/create-self-service-experiences/setup-ui-for-action/advanced-form-configurations?additional-inputs=visible ] would provide more robust, flexible validation, improve user experience, and eliminate the current workaround. Also implementing it as a new feature would make sure nothing breaks for existing users of Port who are using the workaround so negative impact to existing customers would be hopefully non-existent.

Allow categorizing self service actions for ease of finding appropriate actions for your needs.

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