Feature ideas

Allow users to build their own interface components as widgets, with Port's catalog context at hand.

Currently, Ocean metrics webhooks only support passing a webhook URL, adding support for webhook secrets to enhance the security of metrics data sent from Ocean integrations to monitoring endpoints

Currently, when selecting the information ("i") icon and clicking the associated URL, the link opens in the same tab, navigating the user away from the Port environment. To improve usability, these links should open in a new tab or window, allowing users to reference the documentation without losing their place in Port.

Currently, the "Test mapping" in the data source mapping validates only JQ issues. We would like to add more validation such as: "Blueprint doesn't exist" "Property doesn't exist" "Property is invalid" (wrong type, wrong value for enum) etc.

Currently, it's only possible to configure an automation to be triggered on one specific event. For example, when an entity is created or when it gets updated. As developers, building workflow automations, we would like the ability to configure a single automation to be triggered on multiple entity events, allowing us to manage fewer automation resources and avoid code repetition.

When a search relation returns a large number of related entities (e.g., 300+ Functionalities for a Product), it leads to performance degradation or failure. This limits usability in high-volume use cases. The request is to improve search relation handling to support large datasets efficiently

Particularly CREATE actions with the create/update entity backend. CREATE actions will fail if there is an empty required related entity, and the ability to create that entity upon execution using this param like in the API or integration mapping would address this.

Sometimes there is a need to create multiple Port "Workspaces", for example, for staging and prod versions of Port. We would like to add the ability to create several workspaces to an organization and to be able to easily switch between them via Port's UI.

I tried this: { "value": [ "library", "other", "micro-frontend" ], "operator": "doesNotContains", "property": "type" } In hopes that I can filter out types I don't want. But apparently doesNotContains does not support arrays and have to write 3 != rules instead Would be helpful to allow arrays