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.

We want to implement pagination to get entities in the entity page. Some of our catalogs have tens of thousands of entries so it takes a very long time to load those pages.

I frequently build complex multi-condition global search filters to find specific entities, but I have to re-input all filter rules from scratch every time I open Port. It would be really helpful if we could save named custom filter presets to one-click load later, and share presets with teammates in the same organization.

Our users like the ability to click the circle with stars in the lower right and begin a chat with the Port AI. Nearly 100% of the time they are asking about data within our tenant/org. Request - It would be helpful to be able to customize the default AI agent that users talk with, to give it more context and tell it how to respond to certain questions. This would allow for the AI agent to give much better, contextual responses to the everyday Port user.

Background When an Ocean integration starts up, it reads its mapping from .port/resources/port-app-config.yml and applies it to the integration config stored in Port. However, this only happens in two narrow cases: when the integration is being created for the first time, or when it exists but has never been initialized (empty config). In both cases, patch_integration() is called with the port_app_config payload. Once the integration is fully initialized, Port sets arePortResourcesInitialized = true on the integration record. From that point on, every subsequent restart hits an early-return guard in BaseSetup.setup() and skips the entire setup phase. Only metadata fields ( changelogDestination , version , actionsProcessingEnabled , processingMode ) are ever updated via _verify_integration_configuration() - the mapping is never touched. This is intentional: it protects mappings that users may have edited manually in the Port UI from being overwritten on redeploy. Problem The protection has no opt-out, which creates a real friction point for integration developers who manage their mapping in code and expect port-app-config.yml to be the source of truth. In practice this means: Updating the mapping in port-app-config.yml and redeploying silently has no effect - the old mapping keeps running. Running a new version of an integration alongside an outdated mapping is not immediately obvious and can produce confusing behavior. Developers are forced to manually clear or reset the mapping in the Port UI to pick up changes, breaking the "ship code + mapping together" workflow. Proposed Solution Introduce an opt-in configuration flag (e.g. overwrite_config_on_restart , analogous to the k8s-exporter's overwrite-configuration-on-restart ) in IntegrationConfiguration. When enabled: The arePortResourcesInitialized guard in BaseSetup.setup() should not short-circuit. _verify_integration_configuration() (or the setup flow) should call patch_integration(port_app_config=...) with the mapping loaded from port-app-config.yml . The flag should default to false so existing behavior is fully preserved for production deployments where users manage their mappings in the UI. Notes This mirrors a pattern already established in the k8s-exporter ( overwrite-configuration-on-restart ), so there's prior art in the product for this kind of escape hatch. The fix is low-risk when scoped correctly, the default-off behavior means no existing integration is affected unless the flag is explicitly set. A follow-up consideration: whether to expose this flag via an env var, a Helm value, or both, to cover different deployment models.

Description: Currently, the Runs tab in the audit log does not expose approver details as a filterable column. It would be very useful to: Display the assigned approvers and who actually approved a run as columns in the Runs table Allow filtering by approver directly in the UI, without needing to query the API (GET /v1/actions/runs/:run_id/approvers) for each run individually This would improve traceability and auditing of approval workflows significantly.

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.

Description: > Add an "Admin Override" toggle to the core approval settings for Self-Service Actions (SSA) and workflows. Key Capability: > Allows Port Admins to intervene and instantly approve any pending request manually. When the override is used, it skips all remaining approvals in the sequence and immediately marks the workflow as approved.

Currently, there is no "Select All" or "Deselect All" option available for array-type entity inputs in self-service action forms, requiring users to manually select each item one by one — which becomes tedious and time-consuming when dealing with large lists. We'd like to request the addition of a "Select All" / "Deselect All" toggle or checkbox at the top of array-type entity input dropdowns, so users can bulk select or deselect all available items with a single click, significantly reducing friction and improving usability for anyone working with large arrays in self-service action forms.