Feature ideas

Self-service Action RBAC becomes less manageable when housing multiple scenarios/journeys in a single SSA. It becomes confusing for the Admin to mentally track context when establishing/reviewing the RBAC policy and how it applies to various scenarios within the SSA. When I say scenario, what I mean is a specific set of value(s) are selected in the SSA by the executing user, e.g. we may enact a different RBAC policy depending on a form field like environment (e.g. Int, Stage, Prod), or depending on the deployment type (Database, Standard), or even more complex where it's a matrix between both (or potentially even N number of dimensions/fields). For example: In RBAC you can create your own "scenarios" this way, when field A = X, field B = Y, and field C = Z enact RBAC policy 1.

Today a lot of platform engineering teams track regularly how many users logged on, from which teams, when etc... This is to measure usage and adoption. Port customers have that info available through a different link but it would be easier to have it directly in Port, for example in the Audit or in an admin tab. Or even as a user property ("last login") which would give the capability to aggregate and create dashboards.

Currently, the webhook setup in Bitbucket integration automatically creates webhooks across all projects. There’s no option to limit webhook creation to a subset of projects. This creates challenges for teams that want to test or roll out integrations gradually, or only monitor specific projects during development and staging phases.

Today the K8s exporter is able to take a single event/object from the K8s API and create a single entity from it based on the configuration attached to the exporter in Port. In the case of some CRDs (for example, those from Trivy), the CRD itself gets updated overtime with new information, which is stored as an array on the CRD. To make it possible to create multiple entities from the array stored in the CRD, it is required to add a configuration to the K8s exporter that is similar to the itemsToParse ( https://docs.getport.io/build-your-software-catalog/sync-data-to-catalog/webhook/#structure ) capability that currently exists in Port's generic webhooks

Today it is only possible to integrate using basic auth, and this feautre request is about being able to authenticate to SNOW using OAuth

Today we are able to export resources from one environment to another via Terraform for example. However when it comes to UI we have a few limitations: If I create catalog pages in staging and use the API to replicate them in prod, the order might be different and I'm not sure it keeps the same permissions Some widgets might not be supported or options don't stay between the export and import (for example sort order, column ordr) Same for entity pages. The settings I choose in staging cannot be replicated via API in prod without some manual editing in prod We want all our environments to be the same as the lower environment when deciding to promote code. This is true for resources but it is also true for UI. We are missing UI propagation today.

It will be great to have an option in the values to have logging of port integration such as k8s, ocean and agent in JSON format.

Today we can see the total number of entities in a Mixpanel. It would be nice to have that number directly in Port

Currently, markdown widgets on entity pages are static and cannot be dynamically updated once rendered. This limitation affects use cases that rely on live data updates, where the content of the widget should evolve as information changes or new data becomes available. Example Use Cases: Showing live operational updates or status summaries Reflecting changes in linked data sources in real-time Providing dynamic dashboards or continuously updating contextual information

Hi team, In the engineering world, a Technology Radar is a proven way to make tech choices visible and transparent across the organisation. Embedding this capability in the Developer Portal would give engineers a first-stop reference when making decisions, while also tying directly into scorecards and governance. At Serko, we’ve built an in-house Tech Radar (screenshot attached) that’s filterable by system area. This is our go-to guide for any technology choice, with new technologies starting in POC, moving through Trial, Preferred, or eventually Deprecated. This visibility has been invaluable for informed decision-making across the organisation. Our ask: We already maintain this dataset (we can export it into CSV, but it could be more structured if needed). We’d love for Port to provide a Technology Radar UI component (similar to the ThoughtWorks Radar UI: https://www.thoughtworks.com/radar ), where we can connect our dataset and automatically generate this radar view. Let us know if you need a sample dataset in CSV. Looking ahead, this dataset and its blueprint could also power service scorecards, helping us identify if any services are running on deprecated, POC, or trial technologies in production. That insight would directly influence prioritisation, tech debt reduction, and overall engineering health. Our main request is to have the ability to generate this Tech Radar UI view from a dataset. Any thoughts, guidance, or support on how Port can enable this would be greatly appreciated!