Feature ideas

Users see no feedback while jobs are waiting to start (e.g. due to GitHub API rate limits causing 8–15+ min delays). There is no indication of whether the action is queued, rate-limited, or encountered an error during startup. Requested behavior: > Surface early startup/progress states (e.g. "queued," "delayed," "rate-limited") before the workflow produces logs > Show meaningful errors if the job fails to start > Apply across all self-service action types

When you open the edit dialog for a self-service action and close it, it will ask you if you want to continue editing or discard changes whether you made changes or not, this can be confusing because if you had it open for a little while and are actively building it out, you might forget whether you did make changes or not, of course you can simply always save, but it would be nice if a true diff check was made to see if a change is actually present and if not it would simply exit the dialog without asking for confirming about changes that do not exist. Data Sources dialogs already do this, when you edit them you can close without being prompted for confirmation if you made no changes.

Currently it's only possible tying entities to an action run by manually sending an API request to the entities with the run_id - https://docs.port.io/actions-and-automations/reflect-action-progress/#tying-entities-to-an-action-run I'm thinking this should be automated when invoking a self service actions - User clicks on an action --> port system gets the entities affected and encodes them with an action runner run_id - instead of the back and forth in our backend of retrieving both the entities and the action run ourselves and patching them.

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.

Description: Currently, the Runs tab in the audit log does not expose approver details as a filterable column. It would be very useful to: Display the assigned approvers and who actually approved a run as columns in the Runs table Allow filtering by approver directly in the UI, without needing to query the API (GET /v1/actions/runs/:run_id/approvers) for each run individually This would improve traceability and auditing of approval workflows significantly.

I've been trying to set self-service action input defaults on team, array, and string inputs based on properties of the current user or the action's triggering entity. I went through a lot of AI-suggested attempts, but nothing worked. For instance, I have a self-service action that triggers a GitHub Actions workflow to create a git repo. There's an input to choose the team that should be added to the repo with admin privileges, but there's no way to default the team input to, say, the first team in the user's team list. I tried using default as shown below, but it doesn't do anything (I also tried .user.teams[0].name ). It seems that default only supports a static string. "github_admin_team": { "type": "string", "title": "GitHub Admin Team", "icon": "DefaultProperty", "format": "entity", "blueprint": "_team", "sort": { "property": "$title", "order": "ASC" }, "default": { "jqQuery": ".user.teamIdentifiers[0]" } }, I have another workflow to manage users on a team. I spent several hours going back and forth with the AI model trying many different strategies, but none could give me a pre-filled input with the list of current users that I could edit with a user dropdown. I ended up creating an add/remove toggle, and showing a different input for each mode. For removing users from a team, the best I could do was create an unpopulated input and let the operator pick from an unsorted list of every user in the org to build a removal list. "user_remove": { "title": "Users to Remove", "description": "The users to remove from the team", "dependsOn": [ "team", "action" ], "visible": { "jqQuery": ".form.team != null and .form.action == \"remove\"" }, "type": "array", "items": { "type": "string", "format": "user" } }

Currently default is being recalculated, whenever we clear it out. The requirement is to have the default value populate only when the form is first loaded, rather than re-calculating it whenever it is removed.

Currently as it stands, an action can only be associated with one blueprint. It would be great to have an action be associated with multiple blueprints, for example if we want to restart a service, all catalogs will have service overview and likely this action will be associated with service overview entity. In all scenarios there will also be services from respective container orchestration (ECS/EKS) - right now as it stands an action if associated with service overview entity cant be associated with the service blueprint entity - which means a new actions should be created which can be associated with the service (orchestration layer service). The goal here is to be able to use the lightning button and trigger actions instead of going to the action section and triggering it.

Currently, using the dynamic permissions feature, self-service actions will still appear in the UI. In case the user is not permitted, the run will be rejected only after sending the self-service action form. As part of this item, we would like to support hiding/displaying self-service actions using the dynamic permissions policies.

Input-level dataset filters and required field validations in Self-Service Actions are currently UI-side only. Any execution path that bypasses the form UI, JSON mode, direct API calls, or Port's MCP, skips these validations entirely, allowing invalid or unauthorized inputs to be submitted. The desired behavior is for all execution paths to respect the same validation rules defined in the form UI, with meaningful error messages returned on violation. Current workarounds are insufficient for all cases: Dynamic permissions: server-side enforcement, but requires manual policy configuration per action. ownedByTeam: true on blueprint read permissions, restricts entity visibility at the catalog level, but does not cover all use cases.