Feature ideas

Adding instrumentation and analytics for Skills, including visibility into execution metrics such as number of runs per skill, usage trends, and additional adoption insights. Customers would like to understand whether Skills are being used effectively and measure their impact.

Support privatelink between Port and Azure

Goal: Reduce UI clutter and require explicit opt-in to display new properties. Description: Set newly added properties to be hidden by default. Builder/API: Hidden in Entity Details widget and all tables (only meta properties visible). Table (clicking on + Property): Hidden in Entity Details by default. Visible only in the table where created, hidden in all other tables.

Currently, pipelines rely on a generic webhook trigger with a shared endpoint. We'd like support for Jenkins' native "Trigger Build Remotely" option at the pipeline level, allowing each pipeline to have its own authentication token and a unique trigger URL in the format: JENKINS_URL/job/<JOB_NAME>/build?token=<TOKEN> This would allow different backend services to target specific pipelines directly — without shared endpoints or custom routing logic. Desired Behavior Expose a "Trigger Build Remotely" option in pipeline settings. Allow a per-pipeline authentication token to be defined. Each pipeline gets its own unique, independently callable trigger URL.

Where two blueprints have a relationship, we must explicitly set the identifiers of each entity to be linked. I'm proposing something more dynamic - enabling an entity (blueprint A) to be related to one or more entities (blueprint B) based on Search & Query syntax. For example: we want to have a list of "Contributors" to the repository. Given: * a github_repository blueprint * a pull_request blueprint * and a github_credentials blueprint It would be valuable to be able to define a property (aggregate/calculation/other) on github_repository which could list out all github_credentials , related to the repo via the pull_request path, with optional filtering (i.e. only PRs in the last 6 months).

Allow users to define and use customized shared/common properties as dashboard filters, properties that are mapped across multiple blueprints by name or by explicit user configuration. This would enable a single filter (e.g., Package Name) to filter across all blueprints that carry that property, without needing to configure each blueprint separately.

I just need a way to set a custom URL, and set what model I want to use. We're effectively using bedrock, however we want to be able to control credit usage on a per user basis and potentially charge those to their relevant AWS accounts, hence wanting to use a proxy.

We would like to request an enhancement to the Usage Dashboard by adding a Failed executions column to the Action tables. Currently, the tables only include a Successful executions column, which provides an incomplete view of action outcomes. Including failed executions alongside successful ones would give users a more comprehensive understanding, and make it easier to identify failure patterns and overall reliability at a glance.

Summary: Port's aggregation properties support $team (entity ownership) as a path segment, but only when it is the first hop in a pathFilter. When $team appears as a mid-path hop, the traversal silently returns 0 — even when the underlying data is correctly modeled. Example path that doesn't work: EntityA → relation_to_EntityB → $team(_team) → domain Why it should work: Every Port entity already carries a .team[] ownership array. The graph connection exists natively — Port just doesn't traverse it mid-path in the aggregation engine. No additional relation is needed; the data is already there. Current workarounds (all have trade-offs): Add a redundant direct relation (e.g. EntityB → domain) — requires ongoing maintenance Add an explicit _team relation — forces internal Port concepts into the data model Expected behavior: $team should be resolvable at any position in a pathFilter path, consistent with how it behaves as a first-hop segment.

With the new AWS Integration, we would like to ingest data from AWS CodeBuild, AWS CodeDeploy and AWS SES.