Feature ideas

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.

Admins today must create test accounts or guess role inheritance to verify RBAC (mostly for RBAC dynamic policies). This feature gives instant, accurate visibility into the real outcome of permission changes at blueprint scope and for individual entities.

Surface client secret rotation events in audit logs, including who initiated the rotation and when it occurred. This enables to trace unexpected rotations, improve visibility,until approval-based rotation is available.

Current behavior: only admins/editors can add filters; members can only adjust existing ones for their own view. Desired behavior: all members can create their own filters, scoped to themselves, without needing page edit rights. Why it matters: avoids “special orders” per user; “open source filtering” UX for members. Constraints: these filters should be personal to each member's view and not change the global view for others.

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.

By connecting remote MCP servers, like Notion and Atlassian, you can extend Port AI with more capabilities, tools, and data access. For example, ask, "Can you find the latest runbook for incidents in the API gateway?" which will rely on Confluence documentation.

Allow customers to configure and manage SSO directly in Port UI without requiring support or customer success assistance. Proposed Solution: Introduce a self-service SSO feature that enables Port administrators to configure and manage SSO directly in Port UI without requiring support or customer success assistance. This feature should include native support for major providers like AzureAD and Okta, ability to test it before enforcing, and ability to apply additional provisioning like SCIM.

Currently, when a user wants to execute a self-service action (of type: day-2 operation) within a given entity page, they must click the three dots on the far right side of an entity line item or in the top-right corner of the entity overview page. The desired state is to make this incredibly powerful capability more obvious to the end user. In other user interfaces, the three dots tends to be limited in utility (edit/delete/see more info), but the three dots within Port's entity overview page hold a lot of power that should be promoted more actively to the end user.

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.

We recently deployed a SonarQube integration using the hosted solution. Due to our custom IaC setup, we use non-standard blueprint names, but the integration continues to install blueprints and pages with default names. I attempted to disable this using the initializePortResources: false option in the configuration, but it had no effect. It would be helpful to have an option to completely disable the creation of default resources.