Feature ideas

As a Port admin, I want to be able to mirror aggregation properties to carry aggregated data from one blueprint through another blueprint into the "central" blueprint upon which I am building a scorecard.

Introduce support for service accounts within Port to enable automated, non-human access to the platform for integration, automation, and management purposes. This feature would allow systems and services to interact with Port directly, facilitating seamless workflows and enhancing operational efficiency.

Right now API tokens have Admin permissions, they can perform any operation - CRUD operations on the catalog, as well as triggering self-service actions. This feature aims to add support for permissions and RBAC support to API tokens. This would enable for example API tokens with read only access, tokens that can only trigger actions but are unable to directly change the catalog and more.

Ability to assign permissions according to the data model you defined for your organization. How it will work: When assigning permission (for example, to execute an action), the new capability will allow to query the catalog entities and create a permission condition based on the queries. For example: Allowing a developer to execute the "Deploy" action only if the developer is related to the same domain as the service Allowing a user to execute the "Lock/unlock deployments" action only if the user appears in the catalog as the "team leader" of that service The first version will support assigning dynamic permission for executing an action, in the future we will add the support for editing entities.

Support retrieving service dependencies from the Datadog integration.

Currently when you open your user profile via the top right of Port, you're directed to a page showing the internal port user rather than the user entity page. It would be nice if this view would show as an entity showing our custom dashboard we have for our user blueprint.

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.

I want to be able to insert entities by batch or bulk through webhook/REST api to prevent calling the same endpoint many times. I also want to be able to do the same when deleting entities. Having checkboxes in catalogs to select and do a specific action for selected entities can also help :)

Currently, multi select ENUM is only supported by configuration from the UI and API. Adding support for IaC will allow better configuration of the Portal via code, matching the capabilities in the API.

Add the ability to automatically hide optional properties which are not being populated (are null) on the default Overview:Details page of Catalog items.