Feature ideas

Dynamic required fields in SSA forms currently require jqQuery to be written as a single-line JSON string, making complex conditional logic unreadable and difficult to maintain. Allow support for multi-line JQ strings or YAML-based SSA configuration to enable human-readable, maintainable dynamic required field logic.

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

A feature that allows end‑users to use the Filters UI as an input inside a self‑service action form, and on submission, pass the resulting filter JSON so it can be used (e.g., with the Search API) to fetch matching services.

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.

As an example: I have different GH actions configured for provisioning resources on AWS depending on the resource requested: Action A: To provision an EC2 instance Action B: To provision an S3 bucket Action C: To provision an AWS user Action D: To provision a lambda function Action E: To provision a Postgres DB I have a single SSA, "Provision AWS Resource" which contains several advanced inputs which are visible or disappear based on the resource type selected. Due to Port's current setup, I have to combine these 5 GH actions into one since the SSA can only trigger one backend. This will cause my GH action to be huge, convoluted and complex, when I could just configure my SSA to send a payload to a backend (GH action A - E) depending on the resource to be provisioned. Also, I should be able to configure the format of the payload per backend. This allows a single generic SSA but different branches of GH actions (or a different backend pipeline) to be used for complex use cases.

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.

The ability to have the blueprint capabilities on the audit log of action runs. Currently, Port administrators must view the status of action runs (failure, success, awaiting approval, or in-progress) in the action runs audit log. Additionally, visualizations (pie chart and line chart) are limited to blueprints, and do not apply to action runs. As an administrator, I would like to view the success rate of my action runs over time or in a pie chart.

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.

We’re using an INTEGRATION_ACTION with integrationProvider: "GITHUB" and would like to render installationId dynamically from the selected repository’s org_name: "installationId": "{{ . inputs.repository.properties.org _name | ascii_downcase }}" The template renders correctly in the payload preview, but the integration is never invoked (no GitHub workflow run, nothing in the GitHub integration logs). If we hard‑code installationId to "integrationIdentifier", it works. sample: "invocationMethod": { "type": "INTEGRATION_ACTION", "installationId": "{{ . inputs.repository.properties.org _name | ascii_downcase }}", "integrationActionType": "dispatch_workflow", "integrationActionExecutionProperties": { "org": "{{ . inputs.repository.properties.org _name }}", "repo": "{{ .inputs.repository.identifier }}", "workflow": "run-create-vuln-issue.yml", "workflowInputs": { "trigger_user_id": "{{ . trigger.by.user.email | split(\"@\")[0] }}", "base_branch": "{{ .inputs.base_branch }}", "body": "{{ .inputs.body }}", "title": "{{ .inputs.title }}" }, "reportWorkflowStatus": true } } We want to be able for this to work and to select the integration that is running the self service action

Request to add support for time-bound approvals on self-service actions. If an approval is not completed within a configurable time window (for example, 7 days), the action run should automatically expire and be blocked from approval or fail safely. Request motivation: Late approvals can trigger actions that are no longer relevant and may cause unintended or harmful changes.