Feature ideas

When resolving dynamic approvers, only the first 1,000 users in the organization are evaluated, Any users beyond that threshold are skipped, even if they match the required approval groups. Increasing this limit would be helpful.

Problem Statement Currently, Port dashboards require users to manually configure filters with exact property names and values. This creates several challenges: - Users must understand the underlying data model to create effective filters - No support for filtering by common properties that exist across multiple blueprints - Technical workflow not accessible to non-technical stakeholders (managers, executives, product owners) - Each dashboard requires manual filter setup, reducing reusability Use Case As a dashboard consumer (engineering manager, product owner, executive), I want to easily filter dashboard views using simple drop-down selections, so that I can view relevant metrics without needing to understand property names, data models, or filter mechanics. Example Scenario: A DORA metrics dashboard displays data from multiple blueprint types (repositories, deployments, services, incidents). Users want to filter the entire dashboard by a common organizational dimension (product line, team, business unit) that appears across all these blueprints. Current Limitations - Manual filter addition required for each dashboard - Users must know exact property names (e.g., "product", "team", "owner") - Cannot create filters that work across multiple blueprint types - "Contains" property provides only partial workaround - Poor user experience for business stakeholders Desired Solution - Dashboard-level filters with pre-configured drop-down lists - Single-click filtering that applies across all widgets in the dashboard - Cross-blueprint filtering - filter by common properties across different entity types - No technical knowledge required - intuitive UI for filter selection - Reusable filter configurations that can be templated across multiple dashboards Expected Benefits 1. Improved UX - Business stakeholders can self-serve analytics without technical assistance 2. Faster insights - One-click filtering vs. manual configuration 3. Better adoption - Dashboards accessible to broader audience 4. Consistency - Standardized filtering experience across organization 5. Reduced support burden - Less hand-holding required for dashboard consumers Technical Considerations - Port currently cannot filter by common properties across different blueprints - This affects any dashboard showing data from multiple entity types, or a single entity type - Workarounds exist but compromise user experience - Feature would enhance Port's value proposition for executive reporting and cross-functional analytics

Add the ability to support HA for K8S + ocean integrations.

Current behavior: only admins/editors can add filters; members can only adjust existing ones for their own view. Desired behavior: all members can create their own filters, scoped to themselves, without needing page edit rights. Why it matters: avoids “special orders” per user; “open source filtering” UX for members. Constraints: these filters should be personal to each member's view and not change the global view for others.

We want to be able to filter a dashboard according to a timedate property so it will show only the last 3 days. The current predefined options are either use static dates, or choose between in the past day or in the past week. We want to be able to select the number of days in the past or in the future when relevant.

Currently, search conditions cannot be applied to calculated properties in self-service actions. Adding support for this is required

Support for multihop relationship that is both downstream and upstream from the base blueprint in the global dashboard filters For example: Application has a property relation to Service Service does not have a property relation to Application Deployment Frequency has a property relation to Service Therefore the flow is Deployment Frequency -> Service <- Application And we would like to filter the Deployment Frequency based on the Application, a sort of U shaped relationship (downstream to Service and then Upstream to Application)

Add support for breaking down by property in a pie chart for calculation properties, scorecards, and scorecard rules

We are trying to add a new self-service action on Port for a Coming Soon action that will be visible but disabled. We want to be able to be able to not give the user an execute permission but he/she should still see the action with the action button disabled.

With multi-org, people often share port urls with others who are not in the same set of orgs. It would be useful to be able to specify which org should be opened when sharing a url.