Feature ideas

In the demo app, there are several different tag-related self-service actions ("Add Tags to ECR Repository", "Add Tags to SonarQube Project", "Add Tags to S3 Bucket"). Unfortunately, the existing solution leaves a bit to be desired: Two of the examples use an object with key/value pairs, and the third (SonarQube) uses a string field expecting comma-delimited set of values We have tried using an array field for adding tags to existing OpsGenie alerts, but that solution is a bit lacking as well: With a generic field type of "array", the user is taken to a model in order to complete that field...and they must use JSON array syntax in order to provide a value The field is not bound to anything, so there is no way to auto-complete any existing tags (potentially leading to many similar-but-different tags ending up getting persisted) Similar to the tag input field used in systems like Stack Overflow, we would have use for a specific input field type for tags. Ideally, this new field type would simplify user input while also attempting to auto-complete with existing values (similar to a bound entity select field?), so that it is more obvious to a user when they are selecting an existing tag versus explicitly choosing to create a new one.

Currently, search conditions cannot be applied to calculated properties in self-service actions. Adding support for this is required

Ability to cancel the execution of an action after triggering it

In some cases an operation failed and a retry will solve it. Adding a retry action for a run can be nice addition :)

JSON mode should be disabled for Member users, or the ability to disable JSON mode on an action by action basis should be added. This would address permission violations which are possible through using JSON mode (users can successfully execute an action on entities they don't have permissions for).

Current Behaviour: Toggle fields ("type": "boolean") in self-service action form do not currently support the "required" validation. There is no built-in way to enforce that a toggle must be explicitly set to true or false before submission. Problem: Without "required" support, it is impossible to enforce explicit user action on toggles in cases where confirmation or a deliberate choice is critical. This can lead to accidental submissions without the user enabling or disabling important settings. Proposed Solution: Introduce "required": true support for toggle fields so that the form can validate that the user has explicitly set the toggle to the required value before proceeding. Example: "toggle": { "type": "boolean", "title": "Enable Feature", "default": false, "visible": true, "required": true } This would ensure that validation fails unless the toggle is explicitly set to true. Example Use Cases: Explicit Confirmation – Require true to confirm that the user has read and agreed to terms and conditions. Mandatory Feature Activation – Require true to enable a critical feature (e.g., API access, two-factor authentication). Security or Compliance Setting – Require true to enable encryption or logging for compliance purposes. Mandatory Opt-Out – Require false to ensure the user has actively chosen to disable a feature. Mode Switching – Require true to confirm a switch from testing to production mode. Benefits: Adds missing parity with other field types that already support "required". Improves form validation capabilities for boolean fields. Helps ensure critical settings are explicitly confirmed by the user. Notable Workaround: it is a known UX and validation design limitation in many frameworks. The workaround is to use a hidden, required, and disabled input field that depends on the toggle being true. If the toggle is true, the field returns true. If the toggle is false, the field returns null. Because the field is required, a null value will fail validation, preventing the form from advancing to the next step or allowing the user to execute the action.

Port currently uses JQ v1.7.1, which does not support functions introduced in v1.8 (e.g., trim, ltrim, rtrim). This causes confusion when users follow the latest jq documentation or test queries in the official playground. Upgrading to v1.8 would enable these functions, remove the need for regex workarounds, and align Port’s capabilities with the latest jq features across self-service actions, mappings, and exporters.

Right now it is not possible to use JQ when creating conditions for Day-2 or Delete actions. It would be very powerful to have that possibility for advanced searching/filtering of entities

When running actions that include external systems like GitHub Actions or Temporal, it’s hard for developers to understand what’s happening because Port doesn’t show a clear, filtered view of the workflow run (aside from updating a single status). We need a way to visualize the steps that are relevant to them like inputs, approvals, and key external actions, without exposing the full internal logic or backend details that only admins care about.

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