Feature ideas

A new kind of resource has been added to Github - "Enterprise". An enterprise is one level above an organization, and each enterprise contains multiple organizations. So ideally, we would want to be able to install the GitHub app on an enterprise level rather then on an organization level, and integrate with all organizations under that enterprise. That way, we don't need to install the integration on each organization, but we can just install it once per enterprise, and configure the mapping for all orgs through one enterprise. More info about enteprises can be found here https://github.blog/changelog/2024-10-22-enterprises-can-create-github-apps-for-use-within-the-enterprise/

Right now the Input node supports only a static list of users. Adding teams, roles, and dynamic policies will enable more advanced human-in-the-loop use cases. For example: requesting approval from the on-call engineer before deployment outside business hours.

We would like to see the ability to create custom logs at the node level. This could be be conditional logging depending on node outcome. This would also allow messages that make more sense to the user than generic error messages.

In the 'branch' kind, metadata about branch protection rules can be mapped. Having the ability to also map repositories and ruleset metadata would also be helpful.

Some source systems, including Harness cost data, expose required data via GraphQL rather than REST. Without GraphQL support, teams must build and maintain external scheduled pipelines (for example via GitLab) to query source data and push it into Port through the API. Native GraphQL support in custom Ocean integrations would simplify ingestion, reduce maintenance overhead, and keep these use cases inside the integration framework.

Provide audit log functionality for pages so that we can track which users create/edit/delete things like dashboards.

We need support for OpenAPI Specification (OAS) 3.2.0 to be added to Port's OpenAPI documentation renderer. Currently, the renderer supports up to OAS 3.1.0, so using the newly released OAS 3.2.0 encounter version errors . Adding support for OAS 3.2.0 would ensure compatibility with the latest OpenAPI standard, improve the developer experience, and remove the need for customers to downgrade their API specifications as a workaround.

Problem Statement The Usage Dashboard provides a valuable high-level view of Port adoption, but it is difficult to use for deeper product and UX analysis due to limitations in export structure, available dimensions, and analytical depth. Requested Improvements Unified, Structured Export A single export (CSV or Excel) covering multiple widgets or the full dashboard tab, with consistent columns across widgets, rather than separate per-widget exports with varying schemas. Filterable Dimensions in Exported Data Exported files should include key dimensions as columns, such as: Organization Time period User role (member vs. admin) Team Page title Action title Blueprint or feature category Behavioural Analytics Incremental additions to support product and UX analysis: User journey / path analysis: how users navigate between pages or actions sequentially Funnel and conversion tracking: where users drop off in multi-step flows Event-level granularity: individual events with properties such as role, team, feature area, and entry point Session-based views: time between steps, repeat visits within a session, and common sequences before or after key actions Why It Matters These capabilities would allow product and UX teams to make data-driven decisions about onboarding, feature adoption, and navigation without needing to export raw data to external analytics tools for every analysis.

During a bulk import of entities, a workflow that triggers on ENTITY_CREATED was accidentally triggered causing 1k+ invocations of the workflow and subsequent AI nodes, this was a costly incident and we would like the ability to circuit break workflows when they attempt to run a certain number, or at least be able to stagger them so that 1k invocations are not all triggered concurrently.

Add support for opening a self-service action form directly from a custom widget/plugin, without navigating to the Self-Service Actions tab