Feature ideas

We're using Port's IP address restriction (beta), also known as IP whitelisting, to limit access to our Port organizations. Today, any change to the IP whitelist/allowlist has to go through Port's support team, which slows us down. What we'd like: Let org/company admins view and edit the IP whitelist themselves, directly in the Port UI Expose the same through the API and the Terraform provider, so we can manage the whitelist as code alongside the rest of our Port configuration Support a separate whitelist per organization/environment (e.g. prod vs. lower environments) Show changes to the whitelist in the audit log Why it matters: As a regulated company, we need to control network access to every environment we onboard. Depending on support tickets for each change makes it hard to scale Port across our DevOps group and to adjust quickly when our network ranges change.

Synchronous webhook nodes in workflows have a fixed 10-second timeout that can't be changed. When an endpoint, including the Port API itself, takes longer than that to respond, the node fails. Since onTimeout only offers fail or continue and nodes can't be retried, a run that needs that response has no way to recover. Any workflow that depends on a slower API call fails intermittently, with no workaround.

Add native Microsoft Entra ID support to the Ocean custom integration so it can get and refresh Entra access tokens on its own when calling downstream APIs. Today, customers with Entra-protected APIs have to build the OAuth request by hand with custom auth templates, which only work for self-hosted installs, and manage long-lived client secrets. A dedicated entra_id auth type should support client secret, certificate, Managed Identity, and Workload Identity Federation, with automatic token caching and refresh, for both hosted and self-hosted installs. This would unblock enterprise Azure customers whose security policies require secretless authentication.

Some customers would like the option to automatically report Port's information to an external SIEM system for security concern. https://www.ibm.com/topics/siem#:~:text=Security%20information%20and%20event%20management,chance%20to%20disrupt%20business%20operations . First and most important are the changes of Port's audit log

Currently AWS v3 supports a closed list of kinds. whenever a customer requests a kind that is not supported, it requires Port's team to add it to the integration. We would like to allow customers add any kind they need easily similarly to the previous AWS integration (v2)

When a social login provider (e.g. "Continue with Google") is disabled for an organization's domain, users who click it today hit a hard-stop "Login is disabled" page with no path forward, even though the org has a working SSO (e.g. Okta) configured. Instead, blocked social-login attempts should automatically redirect to the org's configured SSO flow, or at minimum surface an explicit "Login with SSO" button on that page. Without this, anyone following a shared link lands on a dead end before ever reaching login, which directly hurts first-time user onboarding and early retention.

Allow categorizing self service actions for ease of finding appropriate actions for your needs.

Port AI in Slack can prepare a workflow run via trigger_run, but the Slack app always requires a human confirmation step and returns a pre-filled form link, even when the skill requests automatic execution. The same trigger_run call can execute automatically outside Slack (for example via MCP or the API). Teams that want chat-native workflow kicks from Slack need an admin-controlled opt-in, such as a per-workflow allowlist or honouring the workflow’s trigger permissions, so selected workflows can start automatically in-thread while keeping the current confirmation default for everything else.

Requesting re-run button/capability for workflow runs. During development and testing, we have to create a new event every time we want to test a workflow change. Being able to re-run a previous workflow run would significantly speed up the iteration cycle.

We would like to call workflows from within workflows. Allow us to conditionally call them via a node.