Feature ideas

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.

Today a delete operation of the file is not deleting the mapped entities from Port in the file kind of Git integrations

For some use cases the 30 character limit is restrictive and limits the capacity for some advanced workflows for auto-generating blueprints from a service prepended with some prefixes. An increase in the character limit would enable advanced use cases/workflows without having to resort to brittle workarounds.

Currently, the catalog filtering options allow for past time filtering, such as "in the past 365 days." It would be beneficial to extend this functionality to include future time filtering. For example, adding a filter like "in the next 365 days" would help us better to present catalog items relevant to future timeframes. In our case we want to have all the future on-call shifts for a user :)