Feature ideas

Self-Service Actions include a "Share" button that generates a shareable link preserving all current field selections - including hidden inputs. This creates a problem when hidden inputs are auto-generated based on the invoking user's context (e.g., current user identity, team, or session data). When another user opens the shared link, those pre-filled hidden values are carried over and may cause the action to behave unexpectedly or fail entirely.

Feature Request: Bulk Selection for Multi-Select Fields Problem: Manually selecting dozens of entities or options in a multi-select field is time-consuming and inefficient. Solution: Add a "Select All" toggle or button within the multi-select dropdown interface to allow users to instantly highlight all available entities. Value: * Efficiency: Reduces friction when handling high-volume data selection. * UX Improvement: Eliminates repetitive manual clicking for large datasets.

When we want to view port as a user, we want to be able to hide the disabled users from the list, so we will be able to only select active or staged users.

Summary Track PR Rework as a key engineering metric - the number of review cycles or post-review commits before a PR is approved. Integrations Should support the following key SCMs: GitHub GitLab Azure DevOps

## Summary Provide support for Approved but Not Merged as a key engineering metric - the delay between PR approval and merge for key SCMs: Github, GitLab, Azure DevOps. Understanding this metric helps team and leadership to improve engineering velocity.

Summary Track Time to First Review as a key engineering metric - the time (in hours) from PR creation to the first review. Provide support for key SCMs - Gitlab, Github, ADO. Why It Matters It helps to investigate team responsiveness and review bottlenecks. Long waits slow delivery and hurt predictability. This is especially an important metric when we combine with AI adoption tracking.

The native GitLab integration in Port does not currently expose the duration field for pipeline entities. We'd like this field to be supported natively. The current pipeline kind mapping fetches data from the GitLab list pipelines endpoint (/api/v4/projects/:id/pipelines), which returns fields such as status , created_at , updated_at , and web_url . However, the duration field is only available on the individual pipeline detail endpoint ( /api/v4/projects/:id/pipelines/:pipeline_id ). What we need: For each pipeline fetched during resync, we'd like Port to also retrieve the detailed pipeline record so that the duration field is available for mapping.

Currently we grab ADO Code Coverage and Test Run results as a part of a sync. As these kinds typically created when a Pipeline Run occurs, we could use the "live event" webhooks from ADO for pipeline runs to call the Code Coverage and Test Run endpoints rather than sync. This would speed up the overall ADO syncs, reduce the change of rate limiting and also provide near-real time data for Code Coverage and Test Runs, inline with the pipeline runs. So when a pipeline run is completed, we should then call the Code Coverage and Test Run endpoints to provide the additional metadata.

Currently the ADO kind for Test Runs containers both Code Coverage and Test Results. These should be separate kinds.

Request for the ability to scope IP address restriction to only block API access, and not UI access. The current beta IP address restriction feature blocks both API and UI access when in use.