Feature ideas

We need Port to support executing self‑service actions as the real user, not as a shared technical account. Today, actions that call tools like GitHub or Jira are executed with an app token, so in those tools every change appears as coming from a generic user. This breaks per‑user traceability required by an external zero‑trust banking audit, is considered a high security risk, and blocks us from safely scaling self‑service to 1,500+ engineers and multiple companies in our group. Requested capability: * OAuth2‑based delegated authorization so each Port user can link their own GitHub/Jira account and actions run with their token. * A consistent “execute as user” model across integrations (GitHub first, then Jira, others later). * Configurable backend for actions: keep current “machine token” mode, and add a new user‑session/OAuth mode that respects Port RBAC and IdP policies. This is a blocker for audit compliance, enterprise‑wide adoption, and for comparing Port fairly with other IDPs that already support per‑user execution.

Currently, when an entity has a URL property, hovering over it displays the full URL, which can sometimes be confusing. What if we showed an alias instead when hovering over the icon of the URL property? This way, it would be easier to understand each icon’s purpose at a glance.

Allow users to build their own interface components as widgets, with Port's catalog context at hand.

We would like Azure DevOps integrations to support incremental sync so that only changed data is fetched and upserted.

With the Port execution agent enabled (with a GitLab/Webhook backend), the headers you configure in the SSA UI are not automatically sent as HTTP headers. By default they stay inside the JSON payload, so you do need a custom “control the payload” mapping in the agent to forward them as headers. In any other case, you can define the payload directly via Port. The request is to have the default behavior to send all the headers configured in the UI automatically.

Hosted by Port ocean integrations can hit out of memory errors at high scale because all integrations get the same fixed resources today. When that happens, customers experience instability in heavier integrations. This feature gives customers a simple way to allocate their total available resources across integrations so heavier integrations get more capacity and lighter ones get less, improving reliability and performance across the board.

It would be very useful to support regex validation on the title key, similar to how regex validation can already be applied to string properties. Reference: https://docs.port.io/build-your-software-catalog/customize-integrations/configure-data-model/setup-blueprint/properties/string/#validate-string

It would be nice to be able to edit the mentioned things via a JSON editor instead of having to use the UI. This would make it easier to copy over repeated patterns of dashboards or restore backed up JSON data.

As of right now we are having to fix the data to a specific format in our number chart. It would be nice to have the ability for the content to be formatted in a way that was more readable to users viewing the data. For example, our change lead time is formatted in minutes, it would be great if it there could be a way to parse the data into a more readable format using months/days/years if it exceeds specific thresholds.

UWM would like end‑users to clearly understand how fresh the data is on dashboards and entity pages. Today, some data source cards (for Ocean integrations) already show metadata like “Last catalog update: X” and “Next resync in Y minutes,” but this information is not visible at the widget or dashboard level. UWM is asking to: Surface “Last data pull at …” (time of last successful integration resync) on DORA widgets/dashboards that depend on those integrations. Potentially surface “Next data pull in … / at …”, based on the configured resync interval / prediction, similar to what’s already shown on some data source cards. This would reuse existing integration‑level metadata and make data freshness clear directly in the DORA experience, without users needing to open the Data sources page.