Feature ideas

When creating an action with approval you can't see who is the action approvers in the run page. That can be helpful to know who can I reach to ask them to approve my run.

We have a few places today where we are attempting to link to a specific self-service action, and have had success using a relative URL like /self-serve?action=[action.identifier] . As an example, we have the following action today: action identifier : create_dbt_repo action inputs : team_name ( enum ), app_name ( string ) It would be nice to be able to default one or more values in the self-service action user input form (on a per instance basis) with a URL like: /self-serve?action=create_dbt_repo&app_name=test . (Note: This is different than defaulting the field at the form level - if someone comes in and manually triggers this action, I don't want to default anything for app_name - but in cases where we are linking to the action from specific pages elsewhere, it would be nice to use the information known at that point to drive some context-specific defaults when they arrive on the self-service action form.)

As a developer using Port's self-service action form, I want the ability to collapse the form into distinct sections such as network configuration, security configuration, and IAM role, So that I can more easily navigate and digest the information, focusing on specific areas as needed based on my answers.

When setting up a day-2 action The ability to create dynamic filter on the list of entities to select just like the other properties in the action (and not load only all the entities of the blueprint)

Add support for invoking multiple triggers in an action while allowing for an Approval to be added between triggers. For example: Have an action triggering a webhook, github, gitlab action. Based on that first trigger result, prompt an approval request and based on the approval, invoke another trigger.

The new secret manager will allow saving secrets/credentials/variables in Port in a secure way. The secrets will be available for reference when controlling the payload of a specific action. This will allow scenarios such as creating a "Create PagerDuty incident" webhook action that sends an API request to PagerDuty with the relevant PagerDuty secrets.

It would be very useful being able to add a link to a port run. uses: port-labs/port-github-action@v1 with: clientId: ... clientSecret: ... operation: PATCH_RUN runId: ... link: ... # <- this will overwrite the existing links It is a known limitation in the API according to https://docs.getport.io/create-self-service-experiences/reflect-action-progress/#run-details : > Note that every patch request will override the previous information that was available for a given key. For example, when updating the link key multiple times, only the last provided value will be displayed in the action run. This is painful in a pipeline for each step which needs to add a new link, without removing the other links, then is required to maintain the whole list. Can you add an option or parameter for adding a link instead of overwriting?

Use JQ to manipulate the payload before sending it to the relevant workflow (Webhook, Kafka, GitHub Workflow, and any other invocation method)

As a DevOps Engineer, I want the ability to create self-service actions directly within Port without the need for predefined blueprints, So that I can quickly and flexibly introduce new processes and tasks tailored to my specific needs.

Currently when developing a new action it can only trigger a workflow that is on the default branch of a repository. It would be useful if a branch could be specified so that when a workflow is being amended it can be tested through Port before being merged.