Feature ideas

We’d like to request an improvement to the current search relevance behavior in catalogs. At the moment, search results do not consistently prioritize exact matches, which becomes especially noticeable when users search for common or ambiguous terms. Even when a resource exists with an exact matching identifier, it is often not surfaced at the top of the results, which creates confusion and reduces confidence in search as the primary discovery mechanism. To improve this, we propose adjusting the search ranking logic to better prioritize exact and high-confidence matches. This would significantly improve usability and make it easier for users to quickly find the intended resource without scanning through irrelevant results. Exact match on identifier or (highest priority) Case-insensitive exact match on normalized name Prefix matches (e.g., “action-*”) Partial or substring matches Fuzzy or loosely related matches (lowest priority) This change would make search more predictable and improve overall discoverability, especially in catalogs where resource names can be highly overlapping or ambiguous.

currently in port API we can set an calculation property's array type item format using items in the payload (API - https://api.getport.io/swagger/static/index.html#/Blueprints/patch_v1_blueprints__identifier_ ). this is not supported yet in terraform provider, could you add the support in terraform provider as well?

Summary Several Port API capabilities have no provider equivalent, forcing customers to fall back to null_resource + local-exec raw API calls. This undermines the value of IaC and blocks Via Transportation from going full production. Gaps SaaS Integrations port_integration cannot set installation type correctly; bootstraps hardcode installationType: "OnPrem" on POST. Workaround: manual API calls. Integration Credentials port_integration only applies mapping config; no way to set credentials or other integration configuration available via the API. Workaround: manual API calls. Integration Resync No way to trigger a resync after creation. Suggested implementation via Terraform provider functions. Workaround: manual API calls. Per-Widget Page Editing Only whole-page replacement is supported; no ability to modify individual widgets. Preferred model: port_page as an umbrella resource referencing widgets by position, with port_page_widget as a configurable child resource. Catalog Page Metadata port_page (including beta) does not expose showInSidebar or section fields. Workaround: not possible via IaC. Page Type Support Only blueprint-entities, dashboard, and home page types are currently supported. Workaround: not possible via IaC. Blueprint Relation/Ownership No first-class resource exists; gaps filled today via external scripts (ensure_blueprint_ relation.py , ensure_blueprint_ ownership.sh ). Native Team Field on Entities Ocean cannot set the team field natively. Workaround: apply_team_ membership.py . Ask Full provider ↔ API parity across integrations (SaaS installation type, credentials, resync trigger), page metadata (showInSidebar, section), and all page types. First-class port_page_widget resource — expose port_page as an umbrella resource referencing widgets by position, with port_page_widget as a configurable child resource supporting partial updates. First-class port_blueprint_relation resource — supporting partial updates and deferred binding to eliminate reliance on out-of-band scripts. Documentation of replace-only fields — e.g. the full widgets JSON on catalog pages, which is currently replaced entirely on every apply

Summary New Port orgs ship with OOTB resources (blueprints, pages, scorecards) that cannot be removed via terraform destroy or any existing provider resource, making it impossible to manage a fully Terraform-controlled org declaratively. Problem A fresh Port org includes resources such as 13 default scorecards that are not needed. While these can be removed manually via the UI, there is no IaC path to do so, breaking the declarative model for orgs intended to be exclusively Terraform-managed. [Slack thread] Ask Extend the port_organization resource (or expose OOTB resources as importable, destroyable Terraform resources) so that a fully Terraform-managed org can declare desired state including the absence of OOTB defaults.

For example , for the graph: Service -> Team -> Team (Parent team) -> Manager Today we can't mirror the manager of the parent team

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.

In the 'branch' kind, metadata about branch protection rules can be mapped. Having the ability to also map repositories and ruleset metadata would also be helpful.

Add an attach_title_to_team query parameter to entity endpoints such as GET /v1/blueprints/{blueprint_identifier}/entities. This would follow the same pattern as the existing attach_title_to_relation parameter, defaulting to false to preserve backward compatibility. When set to true, each team entry in the response would include both the identifier and the title: { "identifier": "team_identifier_1", "title": "My Team Name" }.

When trying to view a path of relations between several blueprints, especially when the data model is complex, it's hard to visually track them. It would be great if the user (all with access to the data model) would be able to highlight the path of relations by clicking the blueprint object (not the expand arrows). For example, by clicking a blueprint, it would be highlighted, and both upstream and downstream related blueprints will be too. By clicking somewhere else the highlighted path will disappear.

Currently in the raw data explorer feature, we are able to search for strings in the raw data. We want to enhance the ability to filter to include creating filters based on columns in the raw data explorer i.e. create a filter for Sync_id = 9b8b7387-0ab5-4633-9e66-51a0f8df80b1 ands resource_index = 3 This will allow us to reach the exact API response we are looking for and allow faster debugging.