Feature ideas

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

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

Today, if a user clicks on the Client Secret rotation by mistake, the key will rotate without approval. So the idea here is to add user approval so the user will approve this request.

As for now the API route for pages and Sidebars are very complex (and it's still in beta), we need to have a better implementation for it

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

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

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.

Currently, the message sender only supports slack. Some organizations use Microsoft teams, which means they cannot create notifications for their teams.

Currently, a dashboard can have many widgets, and each widget that is filter-able has its own filters. As an executive using Port, I want to be able to apply a single filter to all widgets within a dashboard in Port.

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.