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.

Sometimes during entity creation there are cases where you still want to create the entity, but don't want to create a missing related entity. Having this flag would allow for this use case. The entity would be created with the relation identifier included. This would put the entity in a state that is no different than when you delete an entity that is related to another entity and don't delete dependents. The identifier is still in the relation. If the related entity is recreated at some point, the two entities will now have that relationship.

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.

Basically instead of having one view you can modify, have multiple views (similar to Notion tables or Slack lists)

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.