Feature ideas

As a builder, having one scorecard applying to one blueprint means I need to create 3 scorecards for the same criteria which causes friction in the creation, maintenance and visualization of these. Longer description: The same requirement exists across different resource types like deployable units, repos, and host-based apps. With Port’s current model, we need a separate scorecard per blueprint, which turns one concept into many parallel scorecards. That creates a maintenance problem as they could quickly grow into dozens of scorecards and make the team the bottleneck for setup and upkeep. We also want to support unified views of the resulting action items and health status, instead of splitting them across blueprint-specific scorecards.

Currently as it stands, an action can only be associated with one blueprint. It would be great to have an action be associated with multiple blueprints, for example if we want to restart a service, all catalogs will have service overview and likely this action will be associated with service overview entity. In all scenarios there will also be services from respective container orchestration (ECS/EKS) - right now as it stands an action if associated with service overview entity cant be associated with the service blueprint entity - which means a new actions should be created which can be associated with the service (orchestration layer service). The goal here is to be able to use the lightning button and trigger actions instead of going to the action section and triggering it.

Adding instrumentation and analytics for Skills, including visibility into execution metrics such as number of runs per skill, usage trends, and additional adoption insights. Customers would like to understand whether Skills are being used effectively and measure their impact.

Currently, pipelines rely on a generic webhook trigger with a shared endpoint. We'd like support for Jenkins' native "Trigger Build Remotely" option at the pipeline level, allowing each pipeline to have its own authentication token and a unique trigger URL in the format: JENKINS_URL/job/<JOB_NAME>/build?token=<TOKEN> This would allow different backend services to target specific pipelines directly — without shared endpoints or custom routing logic. Desired Behavior Expose a "Trigger Build Remotely" option in pipeline settings. Allow a per-pipeline authentication token to be defined. Each pipeline gets its own unique, independently callable trigger URL.

Enhance user management capabilities by introducing granular visibility and administrative control over Personal Access Tokens (PATs). This includes the ability to view, audit, and manage PATs created by users, as part of broader advanced access governance. Key Capabilities: List which users have active PATs Display PAT metadata: creation date, expiration Enable token revocation through UI or API Support auditability and security compliance This feature would strengthen Port’s administrative tooling by addressing a key gap in access management and improving overall platform security posture.

We’d like to request the ability to hide the Execute button in self-service action forms via a configuration parameter (e.g., hideExecuteButton ). Currently, the button is always displayed, even for forms intended purely for informational or navigational purposes, which can confuse users and limits UI flexibility.

When Port AI interacts via the Slack App, the default output often includes formatting that Slack cannot render correctly (e.g., Markdown tables) or behaviors that are disruptive in shared channels (e.g., @-mentioning groups or users). Current Workaround: We've successfully worked around this by creating a custom "slack-formatting" Skill that triggers by matching the Slack-specific headers (like ## Channel) injected into the prompt. While effective, relying on semantic prompt matching to enforce formatting is fragile. Proposed Solutions: We'd love to see a more deterministic way to handle this. I've thought of _at least_ two, but these aren't meant to be exhaustive: 1) Add a "System Prompt Append" setting within the Slack App configuration. Text entered here would be automatically injected into the system prompt only for invocations originating from Slack, allowing admins to enforce global formatting rules (e.g., "never use tables", "don't use @ handles"). 2) Enhance the Skills feature to support source-based triggers. Instead of the AI deciding to load a skill based on its semantic description, admins could configure a skill to load deterministically whenever the invocation source is Slack.

Currently, when rotating a Port organization's client secret, the old secret is invalidated immediately. This forces a hard cutover and makes coordinated rotations across multiple dependent systems risky and disruptive. We request the ability to have 2 secrets at once so they can be rotated safely. At a minimum, there should be an explicit grace period or deprecation window when rotating, rather than immediate invalidation of the previous secret.

When a Self-Service Action (SSA) run completes, its associated in-app notifications (the red plus 1) disappear. Users who didn't view the notification in time lose visibility into the run's outcome, whether it succeeded, failed, or requires attention. This creates a gap in auditability and forces users to navigate directly to the run history to reconstruct what happened. Users running SSAs asynchronously or across multiple tabs currently have no reliable way to know a run completed without proactively checking the run history. Persistent notifications reduce friction and improve the observability of self-service workflows.

Support privatelink between Port and Azure