Feature ideas

Problem Custom widget plugins have no supported way to use Port's icon library or the icons an organization has uploaded to Port. Neither the plugin SDK nor the plugin bridge exposes icons. Plugins are single self-contained HTML files (up to 10MB) that run under the plugin CSP. Uploaded icons are served through an internal route with signed URLs that plugins can't reach. @port-labs/anchor-icons is on npm, but it isn't documented for plugins and doesn't cover org-uploaded icons. Today, plugin authors have to copy every icon into each plugin by hand. This bloats every plugin and leaves the icons out of sync when the org updates its icons in Port. Use case Richemont builds custom widget plugins for its dashboards and wants them to look like native Port UI, with the default Port icons plus the custom icons it uploaded. In the customer's words: "Do you have a way to expose the Default Port UI Icons and the one that we uploaded into Port to be usable inside the plugins without having to put them manually in each plugin." Proposed solution (most to least preferred) Plugin bridge API, e.g. getIcon(name) / listIcons({ source: 'builtin' | 'org' }), returning SVG markup or a short-lived signed URL for built-in and org icons. Allow the asset origin in the plugin CSP. Officially document @port-labs/anchor-icons for plugins. Add a public endpoint or bridge call that returns the org's uploaded icons. Include the resolved icon asset along with the icon name in the entity and blueprint data passed to plugins. Acceptance: a plugin can render any built-in or org-uploaded icon by name without embedding it, and icon changes show up without rebuilding the plugin. Customer and impact Richemont International S.A. (Enterprise, Contributing devs, ARR 100K-200K). Requester: Thibault ROLAND. Not blocking, but plugins look inconsistent with the portal and the manual workaround has to be repeated in every plugin. This affects any customer building plugins. Related ideas (not exact matches) https://roadmap.port.io/admin/board/ideas/p/enable-plugin-widgets-to-render-port-hosted-markdown-images https://roadmap.port.io/admin/board/ideas/p/add-the-ability-to-access-icons-images-within-markdown-widgets https://roadmap.port.io/admin/board/ideas/p/api-for-custom-icons https://roadmap.port.io/admin/board/ideas/p/larger-icon-library Zendesk: https://getport.zendesk.com/agent/tickets/11975

Currently, Port supports Slack and email notifications for connector sync events, We also need this to support for Microsoft Teams notifications

Description: Port currently lowercases the Entra ID UPN / email when creating the _user entity, so John.Smith@company.com is stored as john.smith@company.com , and _user.identifier cannot be edited manually. Customers who pass user details downstream through self-service actions and workflows to populate case-sensitive RBAC in other systems (for example ArgoCD and Kubernetes) need the original UPN casing, so we request that Port preserve it, either in _user.identifier or in a separate property on the _user blueprint. Customer impact: users cannot log in to kubectl and ArgoCD because of the casing mismatch. The current workaround is a separate Entra ID integration that stores userPrincipalName with its original casing.

Allow dashboard widgets to define their own height dynamically instead of being constrained by the fixed 400px minimum row height, enabling widgets to fill the available space as needed.

Add an org-level setting (UI, API and Terraform) that automatically deletes Port AI invocation records (_ai_invocations entities) older than a configurable number of days. Today these records, which include prompts, responses and tool call details, stay in the catalog indefinitely, so teams with strict data retention policies have to build their own scheduled cleanup against the API. A built-in retention period would let security and compliance teams enforce their policy directly in Port.

Scorecard results (overall level per entity) and their individual rule results are available (as if they were any other property) through various widgets; entity tables, Entity card widget. These are a great way to call attention to a scorecard (particularly when failing) from various views in the portal. However none of them allow a user to click-through and see the scorecard results for that entity. I'm proposing that, wherever the scorecard "properties" are displayed, make them clickable - and they take the user directly to the entity details page, and automatically open the relevant scorecard tab.

We need an option to customise the approval email for a port by adding our own content or modifying the existing email template.

Today, tool approval for Port AI is configured per user, and tools that can run actions, such as run_action and trigger_run, run without approval by default. Admins should be able to set an organization-wide approval policy for Port AI tools, for example requiring approval for every tool that runs actions, that individual users cannot override. This would let security-conscious organizations make sure no action is executed by Port AI without a human approving it, without relying on each user's personal settings.

I would like to conditionally show or hide widgets in my entity dashboard based on some property on my blueprint. For example, have a Service blueprint with a type of "Frontend" would display Frontend specific widgets or dashboard tabs

Some customers would like the option to automatically report Port's information to an external SIEM system for security concern. https://www.ibm.com/topics/siem#:~:text=Security%20information%20and%20event%20management,chance%20to%20disrupt%20business%20operations . First and most important are the changes of Port's audit log