Feature ideas

It would be great to have an option to do bulk actions(day2 and DELETE) on entities

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.

When selecting an entity the user can see and filter by the title and id of the entity. For some entities this is not sufficient as it might not be enough for the user to understand which entity to select when multiple entities can have the same title and the id is an a meaningless integer. e.g. selecting a gitlab group. there can be multiple group with the same name. In the drop down list we'll see multiple such entities and below each there will be their int id but what we really need to be able to show is the full path of the group so the user can understand which of the multiple entities is the one they really intend to operate on.

Currently, the "My runs" side panel only displays action runs that executed by the current user We would like to display in the "My runs" side panel, all the action runs that need to be approved by the current user, even if the run was executed by other users.

Introduce an onboarding wizard feature that allows Port admins to create interactive, step-by-step guides tailored to their organization’s needs. These wizards can include: Customizable steps with explanations and actions Embedded tooltips and guidance prompts Conditional branching based on user role or preferences Progress tracking and completion status Integration with Port’s self-service actions Key Benefits: Enhances user onboarding experience and accelerates time-to-value Reduces reliance on admin-led training and support Ensures consistent and structured user education across teams Drives engagement with Port’s features, increasing adoption

For certain actions it would be helpful to have a bigger text area (like the description when creating a Jira issue ) with the ability to add links, images, and videos

In some cases, we may want to create a certain default value for a field based on previous selection made by the user. This can include literals and even multiple fields references. The default value should be adjusted automatically until the field becomes visible.

As an admin, I'd like to see the return status and body for webhook self-service action backends

Today if a user enters text to a string based input field for a Self Service Action that happens to be invalid determined by a Regex match pattern. The user is presented with a red font colour error message in the format "must match pattern {regex-pattern-here}". Even though we have a human readable validation hint message on the field description. We've had numerous users not find that and instead become blocked and distracted by the red error which they don't understand. To avoid them reaching out to a admin/action owner for support. I would like to be able to set a custom match pattern error message text. If set the user see's my error message and not the default one. So in my guess here I would say something like "Name use lower case characters a-z or numbers 0-9 but can't start with a number. Name must be at least 3 characters long".

Imagine a self-service action where some of the inputs are known from the context of the entity being operated on or the user. It would be nice to be able to show to the user these bits of information for verification but not allow them to change it by making the field grayed out and disabled. Example: Promote a Build to the next environment. All the context is known from the Build e.g. version, service being deployed, and related story, current environment and thus next environment. Each of these fields will be automatically populated from the entity context and the fields grayed out. It may also be nice to distinguish between when an SSA is operated from context i.e. from an entity versus from the self-service library without context. That knowledge of SSA origin could be used to dynamically set those fields as disabled or not without the need to duplicate the SSA, one for disabled fields when operated via context and one with enabled fields for when operated from the SSA library.