Feature ideas

Would be very useful to have the ability to select multiple entities on the page and bulk delete them all

Support excluding Resources based on tags applied to their parent Resource Group. In some cases, individual Resources lack the relevant tag, while the Resource Group has it. Tagging every Resource may not be practical, and relying solely on Resource-level tags introduces risk. It would be helpful if the Azure incremental-sync integration or the mapping logic could support exclusions based on Resource Group tags. This would improve flexibility and reduce reliance on consistent tagging across all Resources.

Allow users to build their own interface components as widgets, with Port's catalog context at hand.

There are some blueprints that I always want to exclude from global search (e.g. releases). When they are included, it ruins the search results. I want to be able to configure it globally, i dont want to have to add a search expression to the global search

Extend the OpenCost Ocean integration to include the /assets endpoint https://opencost.io/docs/integrations/api/#assets-api This would allow for more granular costings.

Currently the ADO File Kind does not support Wildcard/globs as per https://docs.port.io/build-your-software-catalog/sync-data-to-catalog/git/azure-devops/examples#capabilities-and-limitations . This is required to help map things like mono repos.

If you have custom Github app(s) installed (same Github org), there is no way to select which app is used in actions. Would like the ability to select which Github app is used in the action backend, possibly with a dropdown option.

Widgets on an entity dashboard need to be dynamic. For example iFrame implementation on entity dashboard should use the entity info to display the appropriate URL (maybe {{.entity.url}}) - Need to make URL portion dynamic Markdown should be dynamic as well for a better user experience

The naming standards for some blueprints and their properties are inconsistent. If we look at something like the ADO Integration and the blueprints. * ADO Project - BP Identifier: "project" * ADO User - BP Identifier: "azureDevOpsUser" Additionally if take the ADO User BP identifier, it uses camel case whereas auto generated properties will utilise snake case. As a builder, by improving the naming standards/conventions, this would help remove ambiguity around things like mapping relations, utilising properties in widgets etc.

External datasources which need authentication would benefit from a "Test Connection" button on the configuration screens, like Grafana does for Data Sources