Feature ideas

Currently when you set the blueprint identifier for a Day-2 Self-Service action, its entity is placed automatically at the top of the form inputs without the option to control its order. There could be scenarios in which the selection list of the target entity is too large and it gets complicated for the user to figure out what instance to choose. This is a limitation that prevents you from having input filters placed before the form's target entity that will help you narrow down the options for the selection list of the target entity. Example: You have 3 entities A, B and C. The relations goes like this C -> B -> A. If I have a Day-2 Action that takes action on the entity C, I want to be able to include the A and B entities in the form and be able to select them first (for filter purposes) before choosing directly between the instances of C, because unfiltered, there could be a lot of C instances to choose from, and it gets hard to identify the exact instance that you need only by checking its name (not knowing the relation to A and B).

When using regex to validate fields value we either have to not provide a default value or provide a valid value. It would be useful to be able to set placeholder value to give user an example but forcing them to set a new value. This prevent the case where the action is wrongly submitted with the example default value.

issue created here https://github.com/port-labs/terraform-provider-port-labs/issues/116

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.

We would like to be able to consume from multiple topics as we are planning to have multiple port-agents - one running on each of our clusters. These clusters do not and can't have network connectivity between them which means we can't use a single port-agent to trigger multiple endpoints.

Today using dynamic properties (getUserEmail, getUserTeams) is not available in day-2 action conditions, so that we will be able to have advanced filtering based on user relations

This capability enables use cases such as where survey creators need to restrict the number of choices a respondent can select

When clicking on the '...' to edit or delete an action, it can be cool to duplicate the existing action with the inputs and configuration and just modify the diff

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.

In certain scenarios in bigger organizations it is not unusual to have an approval flow that will involve more than one team. The review for a request can be done in * parallel - request denied by any of the teams would stop the workflow * sequentially - request review progress to the next step only after the previous team has approved Even a basic implementation on top of the existing could provide a lot of value and further anchor the use of the portal as a coordination tool for processes and teams.