Feature ideas

Support configuring a minimum number of required approvers for actions that require manual approval (e.g., “at least 2 approvers” or “2 out of N”), as the current options only allow either a single approver (“Any”) or requiring all approvers (“All”). While dynamic permissions can define who is eligible to approve, they do not control how many approvals are required. Introducing a configurable approval threshold (such as a fixed number or majority) would provide greater flexibility and eliminate the need for workarounds.

As a builder, having one scorecard applying to one blueprint means I need to create 3 scorecards for the same criteria which causes friction in the creation, maintenance and visualization of these. Longer description: The same requirement exists across different resource types like deployable units, repos, and host-based apps. With Port’s current model, we need a separate scorecard per blueprint, which turns one concept into many parallel scorecards. That creates a maintenance problem as they could quickly grow into dozens of scorecards and make the team the bottleneck for setup and upkeep. We also want to support unified views of the resulting action items and health status, instead of splitting them across blueprint-specific scorecards.

Currently as it stands, an action can only be associated with one blueprint. It would be great to have an action be associated with multiple blueprints, for example if we want to restart a service, all catalogs will have service overview and likely this action will be associated with service overview entity. In all scenarios there will also be services from respective container orchestration (ECS/EKS) - right now as it stands an action if associated with service overview entity cant be associated with the service blueprint entity - which means a new actions should be created which can be associated with the service (orchestration layer service). The goal here is to be able to use the lightning button and trigger actions instead of going to the action section and triggering it.

As a builder, I want to show data in widgets that comes from a calculation of multiple properties e.g. I want to do a claculation on the number of PRs opened just for this one graph, so I can use jq to calculate the data output.

Customers using the Aikido Ocean integration needs team ownership surfaced at the issue group level, not just on individual issues. Their teams use included_paths to define responsibility, and while individual Aikido issues map correctly to teams via affected_file, issue groups only expose repository-level data — so the same matching can't be applied. The natural workaround (relating issue groups → child issues → teams via mirror properties) is blocked by the 500-entity search relation cap, since groups can have hundreds of child issues. A simple SET aggregation also doesn't meet their needs — because individual issues can belong to multiple teams, they need a distinct list of teams per issue group, making this a true many-to-many relationship. Requested: Add a native team dimension to the Aikido integration by leveraging Aikido's own team→issue group mapping: GET /api/public/v1/teams GET /api/public/v1/open-issue-groups?filter_team_id={ team.id } This would expose a team_issue_groups resource (or equivalent relation on issue groups) with the distinct set of owning teams per group — modelled as many-to-many. Without this, the customer is forced to build and maintain an external scheduled aggregation job.

In bar charts for example, if I use a property, it defaults to the value of the property. In our case, if the usage is done in a numbers (the property values) we would like to group that data by user so we can see the numbers for each user on that property/

We want to have additional properties in the Wiz Ocean integration We want to change the mapping and return it for doing the proper mapping in the integration. * we would like to have vulnerableAsset information for all the VulnerableAssetsTypes . A full example of VulnerableAsset for ContainerImages and a small subset for the rest of the other types are seen in the code snippet below: query VulnerabilityFindingsTable( $filterBy: VulnerabilityFindingFilters $first: Int $after: String $orderBy: VulnerabilityFindingOrder ) { vulnerabilityFindings( filterBy: $filterBy first: $first after: $after orderBy: $orderBy ) { nodes { id severity categories version detectionMethod score status description resolvedAt updatedAt firstDetectedAt publishedDate remediation environments link vulnerabilityExternalId portalUrl origin CVEDescription name detailedName artifactType { group ciComponent custom plugin osPackageManager codeLibraryLanguage } hasFix hasExploit isHighProfileThreat projects { id name } rootComponent { name } applicationServices { id } vulnerableAsset { ... on VulnerableAssetBase { id type name cloudPlatform subscriptionName subscriptionExternalId nativeType } ... on VulnerableAssetVirtualMachine { id type name cloudPlatform operatingSystem nativeType } ... on VulnerableAssetContainerImage { Core identification fields id type name cloudPlatform Subscription/Account information subscriptionName subscriptionExternalId subscriptionId Resource metadata tags nativeType Network exposure fields hasLimitedInternetExposure hasWideInternetExposure isAccessibleFromVPN isAccessibleFromOtherVnets isAccessibleFromOtherSubscriptions Container-specific fields repository { name } registry { name } scanSource Execution context (where the image is running) executionControllers { id entityType externalId providerUniqueId name subscriptionExternalId subscriptionId subscriptionName ancestors { id name entityType externalId providerUniqueId } } Additional fields from Splunk integration imageId region providerUniqueId cloudProviderURL status } ... on VulnerableAssetContainer { id type name cloudPlatform nativeType } ... on VulnerableAssetServerless { id type name cloudPlatform nativeType } ... on VulnerableAssetRepositoryBranch { id type name cloudPlatform repositoryId repositoryName nativeType } } } pageInfo { hasNextPage endCursor } } } This will allow us to get the additional information we need in our catalog.

Add the ability to configure the number of hops shown in related entity views. For example, setting maxHop = 1 would display only directly related blueprints, rather than showing all possible paths by default.

Have filter fields auto-adjust to the size of the items in the list. As an example, when adding a filter by team, at first the box for the teams is too small to read any of the teams but once a team is selected, it resizes the box and then it becomes easy to read.

Introduce native support for displaying a predefined, clickable URL as a structured UI element within self-service actions, without requiring user input fields or relying on a “Trigger” button as the primary interaction. While Port currently provides several ways to surface links, none fully support a clean, static “informational redirect” experience within self-service actions. For example, action descriptions can include markdown links, but they lack consistent behavior control (such as enforced new-tab navigation) and are not intended to serve as primary UI navigation elements. Similarly, disabled or informational fields within action forms are read-only and cannot reliably function as interactive link components. The proposed solution is to introduce a static link / redirect UI component for self-service actions with the following capabilities: Display a predefined URL as a first-class UI element (link or button) within the action interface Support optional custom display text, similar to labeled URL properties Require no user input, with the URL defined at action definition time (optionally templated from context such as entity or user fields) Open links in a new browser tab by default, consistent with existing external link behavior Function as a primary CTA alternative to the Trigger button, enabling a cleaner “informational or redirect-only” action type Optionally integrate with existing audit/execution tracking to measure link usage