Feature ideas

As admin users, we have full visibility on everything that's available in Port. We can already control what users see and interact with, but we cannot easily confirm if the changes we have made are correctly tailored to them. It would be very helpful to be able to preview the changes.

As described here , the "policy" key for entity permissions is currently supported for the "read" permission type. As part of this item, we would like to add support for create, update, and delete operations as well.

Current behavior The Usage Dashboard is automatically visible to all Org Admins in Pro & Enterprise orgs. [Usage dashboard announcement] This access cannot be changed or restricted today; all Org Admins always see it. Problem Usage and billing‑related data is sensitive. Organizations want least‑privilege access and the ability to limit visibility to a small group (e.g., platform owners, FinOps, auditors), not all Org Admins. Requested change Add RBAC controls for the Usage Dashboard Configure who can view it by: Roles Specific users Teams This should be similar in spirit to existing page permissions (view/edit by roles/users/teams). Configurable default behavior Keep current default (all Org Admins) for backward compatibility, but allow organizations to override it (e.g., restrict to selected roles/users/teams) Impact Better alignment with least‑privilege and compliance requirements. Consistent RBAC story across Port (catalog pages, dashboards, and platform‑level features like Usage Dashboard).

Add property-level read permissions, adding to the edit permissions for properties that Port already provides.

I would like more control over what permissions admins can have within the IDP. For example, some admins can only edit automations, and webhooks, some admins can only edit the data model, or no admins can generate a new org token. This enables following of least privilege principle. The "superadmin" role could do anything. Usecase: Our team is building a pipeline to version control data model changes as JSON, it would be nice if no one can update the data model through UI in our production environment anymore and they can only do it through the pipeline.

Currently, the SCIM integration operates in the background to ensure secure access to Port. However, it is not fully integrated into the application—provisioning does not add users to Port, and deprovisioning does not remove them. Ideally, the SCIM integration should be fully implemented and seamlessly connected with Port.

Managing dynamic permissions requires specific skills and is more challenging to debug and verify. To assist, we want to provide an improved UI that will allow us to test the result and verify users defined the permissions as expected.

I think it would be helpful for UX to be able to change its own profile image directly in Port UI.

Today you can only manage service accounts in Port via the API.

Hi! We are trying to implement a small public-facing page that will be an API-Hub. Then our customers could get a good experience when using SwaggerUI in Port. The problem is that the user with the lowest level of access (Viewer) still sees a large amount of information that he does not need, and sometimes information that should be hidden at all. It would be great to control what the Viewer sees in more detail. As in my example, to prohibit tabs from being seen. I'm attaching some screenshots on behalf of the Viewer, as an example of the expected appearance of the page