Feature ideas

The ability to use substring or regex matching inside Port’s search rules, especially when the target property is an array of strings (such as tags). This could be via: a dedicated operator like containsSubstring / matches, or allowing regex patterns in value (e.g. ^service:{{serviceTitle}}). { "property": "tags", "operator": "matches", // or similar "value": ". {{ .event.diff.after.title }}. " }

When the user focuses the search bar, show a list of their recently searched blueprints to help them quickly re-access common queries.

Currently breadcrumbs in catalog pages are static text. It is expected and would be very convenient if they behave as links to the corresponding level.

Currently, deep links (especially external ones) open in a new browser tab by default, which can disrupt workflow. We request an option to configure whether links open in a new tab or within the current browser window, allowing for smoother in-app navigation and a more seamless user experience.

Similar to the URL param that populates the search box on the data sources page (e.g., https://app.us.getport.io/settings/data-sources?filter=repo ), add a URL param to the self-service action page. This would allow hyperlinking to a subset of actions based on name/description (e.g., https://app.us.getport.io/self-serve?filter=repo ).

I would love to use icons for the sidebar folders for better visibility

When a search relation returns a large number of related entities (e.g., 300+ Functionalities for a Product), it leads to performance degradation or failure. This limits usability in high-volume use cases. The request is to improve search relation handling to support large datasets efficiently

Context https://docs.getport.io/search-and-query/#relation-structure-and-operators describes how to search for Entities that have a relation to other Entities. This can be used with the search API ( https://api.getport.io/v1/entities/search ) and with the filters when adding a visualization to a dashboard for example. This type of search only has one operator: relatedTo . Objective Add an opposite operator, i.e. relatesNotTo . Rationale Sometimes the business context dictates that certain relationships SHOULD be present in the data. By adding this operator it becomes possible to find inconsistencies in the data by searching for Entities that do NOT have a relationship (where one is expected).

When querying the Audit Log API for entity updates, the actor is returned as a userId. There’s no direct way to resolve that ID to a name/email. Today we must fetch all users in the org and filter those results client-side. Please add a direct resolution path (such as GET /v1/users/{userId} or GET /v1/users?ids=<id,...>) or allow filtering the Users API by id.

Currently we can provide a URL pointing to a tab that shows the rendered spec for swagger/openapi files but we cannot link to specific endpoints inside it. This would help our backend & frontend teams better coordinate together when working on features.