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.

Support configuring a minimum number of required approvers for actions that require manual approval (e.g., “at least 2 approvers” or “2 out of N”), as the current options only allow either a single approver (“Any”) or requiring all approvers (“All”). While dynamic permissions can define who is eligible to approve, they do not control how many approvals are required. Introducing a configurable approval threshold (such as a fixed number or majority) would provide greater flexibility and eliminate the need for workarounds.

We'd like to enable identity or user session propagation capabilities, allowing Self-Service Actions (SSAs) triggered within Port to be executed using the context and permissions of the currently logged-in user. When an authenticated user initiates an SSA that interacts with external systems or resources, the action should be performed on behalf of that user, inheriting their identity, role-based access controls (RBAC), and authorized privileges from the same Identity and Access Management (IAM) provider used by Port, which is Okta. For example, if an employee triggers an SSA to update a ticket in a service management system like Jira, the update should be carried out using that employee's credentials and permissions within Jira, which are derived from the same Okta IAM provider that Port uses for authentication and authorization. Similarly, if an SSA involves provisioning resources in a cloud platform, it should leverage the logged-in user's identity and access rights from Okta to ensure the provisioning adheres to their authorized roles and scopes defined within the shared IAM provider. By propagating the user's identity and session context from the common Okta IAM provider, we can maintain a consistent access control model across Port and integrated systems, ensuring that actions are performed with the appropriate level of authorization and adhering to the organization's security policies and governance rules defined within the centralized Okta IAM solution.

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.

There is currently no way to control the order of Day‑2 operations (self‑service actions) on an entity dashboard / via the “thunder” icon. They are sorted by action creation date.

Currently, permissions are scoped to users and roles, but there is no way to restrict an action to specific invocation channels (e.g., UI only vs. MCP). This is a concern for high-risk operations such as production deployments, where teams want the additional guardrails and visibility that the Port UI provides. Relying on the Claude/MCP client config to restrict actions is fragile — it lives outside Port's governance model, isn't auditable in Port, and can be bypassed or misconfigured. Native support in Port ensures consistent enforcement across all MCP clients and aligns with existing RBAC patterns. Adding an invocation source control at the action level in Port, allowing admins to configure which channels an action can be triggered from would allow teams to enforce that sensitive actions (e.g., prod deploys, destructive operations) cannot be triggered via MCP, without needing to rely on external configuration in the AI client (e.g., Claude system prompt restrictions).

Introduce native support for displaying a predefined, clickable URL as a structured UI element within self-service actions, without requiring user input fields or relying on a “Trigger” button as the primary interaction. While Port currently provides several ways to surface links, none fully support a clean, static “informational redirect” experience within self-service actions. For example, action descriptions can include markdown links, but they lack consistent behavior control (such as enforced new-tab navigation) and are not intended to serve as primary UI navigation elements. Similarly, disabled or informational fields within action forms are read-only and cannot reliably function as interactive link components. The proposed solution is to introduce a static link / redirect UI component for self-service actions with the following capabilities: Display a predefined URL as a first-class UI element (link or button) within the action interface Support optional custom display text, similar to labeled URL properties Require no user input, with the URL defined at action definition time (optionally templated from context such as entity or user fields) Open links in a new browser tab by default, consistent with existing external link behavior Function as a primary CTA alternative to the Trigger button, enabling a cleaner “informational or redirect-only” action type Optionally integrate with existing audit/execution tracking to measure link usage

As an admin, I'd like to see the return status and body for webhook self-service action backends

We’d like to request the ability to hide the Execute button in self-service action forms via a configuration parameter (e.g., hideExecuteButton ). Currently, the button is always displayed, even for forms intended purely for informational or navigational purposes, which can confuse users and limits UI flexibility.

When a Self-Service Action (SSA) run completes, its associated in-app notifications (the red plus 1) disappear. Users who didn't view the notification in time lose visibility into the run's outcome, whether it succeeded, failed, or requires attention. This creates a gap in auditability and forces users to navigate directly to the run history to reconstruct what happened. Users running SSAs asynchronously or across multiple tabs currently have no reliable way to know a run completed without proactively checking the run history. Persistent notifications reduce friction and improve the observability of self-service workflows.