Feature ideas

Problem Statement Port's 100-character identifier limit makes it impossible to reliably create unique, deterministic identifiers for documentation entities using natural keys (repository + filepath), which frequently exceed this limit. There is currently no built-in way to generate SHA hashes from property values during entity creation, forcing users to choose between: Truncated paths → Risk of identifier collisions Manual hash generation → Inconsistent, error-prone, requires external tooling Filename-only identifiers → Guaranteed collisions (multiple README.md files) Current Constraints Identifier Limit Maximum identifier length: 100 characters Pattern requirement: ^[A-Za-z0-9@_.:\\/=-]+$ Real-World Examples Exceeding Limit Example 1: GitHub Documentation Path Repository: tr/platform-engineering-kubernetes-infrastructure File path: .github/PULL_REQUEST_TEMPLATE/pull_request_ template.md Natural identifier: tr/platform-engineering-kubernetes-infrastructure/.github/PULL_REQUEST_TEMPLATE/pull_request_ template.md Character count: 109 characters Example 2: Deep Documentation Structure Repository: atpa-gst-ai-assistant File path: documentation/architecture/backend-services/authentication/ oauth-integration-guide.md Natural identifier: atpa-gst-ai-assistant/documentation/architecture/backend-services/authentication/ oauth-integration-guide.md Character count: 114 characters Example 3: Long Repository Names Repository: thomson-reuters-legal-technology-innovation File path: docs/deployment/kubernetes/ production-configuration.md Natural identifier: thomson-reuters-legal-technology-innovation/docs/deployment/kubernetes/ production-configuration.md Character count: 117 characters This is critical for us as: Blocks core functionality: Can't reliably upsert entities Forces workarounds: External scripting required for all integrations Data quality issues: Identifier collisions cause data loss Operational overhead: Manual identifier management doesn't scale Architecture constraint: Limits usefulness of Port for documentation management

When pressing the browser back button (or the back icon in Port) you are taken back to the previous entity you had selected and not the previous page (which is what I would've expected).

Allow global/Spotlight search to be filtered or ranked by type, with admin controls to exclude noisy entities and prioritize services.

Currently, global search results are based solely on the keyword(s) entered. For organizations with many entities, it would be helpful to do a few things with global search, such as: filtering (provide filters to the search using a search dropdown for blueprint, properties, relatedTo, etc), semantic search, and adding filters within the search query (such as in:<blueprint>, <search query A> AND <search query B>, NOT <blueprint>)

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.

Today you can only use relatedTo to check if an entity is connected to a certain entity on a related blueprint. When using Port I'd want also to check the entities that are not connected at all to any entity in the related blueprint. For example - All Workloads that are null in the "Namespace" relation

I would like to suggest a navigation improvement for the entity detail page. Currently, at the very top of the page (above the main title), there is a text path indicating the hierarchy, e.g., Platform Request / Permission to ai-sandbox account. The first part of this path (the Blueprint name, e.g., "Platform Request") is currently static text. Please turn the Blueprint name in the top breadcrumb trail into a clickable link.

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).

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 }}. " }