Feature ideas

In the Azure Resource Graph integration, we can filter resources by the resource group tags. To filter resources by resource tags, we have to update the query in the selector which filters the data after it has been fetched. Filtering at the point of querying the data from Azure Resource Graph would be an optimization and potentially increase performance. In our dataset, we'd go from querying almost 250k VMs to 33k VMs from Azure Resource Graph.

Embed the documentation directly in the integration-installation modal. This keeps users in flow, gives them step-by-step guidance without switching tabs, and helps prevent setup or permissions slip-ups.

Would be beneficial to have markdown from Notion as datasource to Port, probably as a notion integration

Currently the azure devops ocean integration only supports webhooks for the following: git.pullrequest.created git.pullrequest.updated git.push git.repo.created We want all relevant service hook events supported. In addition to the ones listed above, we want Pipeline, Pull Request, Repository, and Work item events. We currently have custom webhooks, but we have to maintain duplicate mappings. One in the ocean integration and the other in the custom webhook. https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops Here is a list of the specific service events. The * indicates ones we are currently using in custom webhooks. Check updated Manual intervention pending *Run state changed *Run stage state changed Run stage waiting for approval Run stage approval completed Run job state changed *Pull request created Pull request merge attempted *Pull request updated Pull request commented on *Repository created *Repository deleted Repository forked *Repository renamed Repository status changed *Work item created *Work item deleted *Work item restored *Work item updated *Work item commented on

Currently, AWS CICD toolkits are not supported directly in Port.

Add the secret-scanning-alerts kind to the Github Ocean (self-hosted) integration.

Currently, the webhook setup in Bitbucket integration automatically creates webhooks across all projects. There’s no option to limit webhook creation to a subset of projects. This creates challenges for teams that want to test or roll out integrations gradually, or only monitor specific projects during development and staging phases.

Add support for GitLab System Hooks to enable instance-wide webhook configuration using an admin token. This would allow a single webhook to capture events from all groups and projects across the entire GitLab instance. The GitLab integration currently only supports group-level webhooks. This means the integration must configure webhooks for every group separately in an organization separately.

Today the K8s exporter is able to take a single event/object from the K8s API and create a single entity from it based on the configuration attached to the exporter in Port. In the case of some CRDs (for example, those from Trivy), the CRD itself gets updated overtime with new information, which is stored as an array on the CRD. To make it possible to create multiple entities from the array stored in the CRD, it is required to add a configuration to the K8s exporter that is similar to the itemsToParse ( https://docs.getport.io/build-your-software-catalog/sync-data-to-catalog/webhook/#structure ) capability that currently exists in Port's generic webhooks