Feature ideas

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.

In some cases, when defining a self-service action, there is a need to allow running this action on specific entities. For example, allowing to perform a "Deploy to Prod" action only on services with a high production readiness scorecard. For this scenario, we would like to add "Filters" when defining actions, so the action can be performed only on entities that pass the filter.

The new "Create/update entity" invocation type for self-service actions and automations will allow updating catalog entities as part of a self-service action form/automation execution For example, creating a specific self-service form for updating the Service team and Tier directly in the catalog.