Feature ideas

Terraform can only manage existing integrations — it can't create new ones yet. We do not have the APIs to create integrations via API or Pulumi or Terraform today

The GitHub Ocean integration should ingest membership data for GitHub Enterprise Teams ( ent:* slugs) in the same way it does for standard organization teams. Today, enterprise teams are discovered and synced as team entities in Port, but their member relationships are not populated. The enrichment flow relies on GraphQL organization.team(slug) , which returns null for enterprise-managed teams ( ent:* ), causing member enrichment to be skipped while the team entity itself is still created. As a result, enterprise teams appear in Port without their members, creating an inconsistency between enterprise-managed teams and standard organization teams. This feature request is to add support for ingesting and maintaining membership relationships for GitHub Enterprise Teams.

The Port AI API allows invoking the assistant with a prompt and receiving a response programmatically. However, there is no way to open the Port chat UI with a prompt already populated. The desired behavior is a mechanism (URL parameter, deep link, or SDK call) that opens the Port Assistant chat interface and pre-fills it with a given prompt, so the user lands in the chat UI and can see the response rendered there rather than receiving raw API output. This would be useful for actions and automations that want to hand off to a conversational context instead of silently executing in the background. For example, from a plugin we could invoke the Port Assistant with a prompt for the user to get them started with a live chat session. Reference: https://docs.port.io/ai-interfaces/port-ai/api-interaction

When changes are made to dashboards, widgets, scorecards, or other UI elements in Port, end users do not automatically receive the updated view. Currently: A hard refresh (or clearing browser history/cache) is required to see new changes. A soft refresh is sometimes insufficient Proposed Solution (from @galtomer) A config/version check or ETag-based mechanism that busts the locally cached view whenever a dashboard, widget, or scorecard is changed on the backend. This would ensure users automatically receive the latest UI state without manual intervention.

Current State: Port supports generating pre-filled action execution URLs for self-service actions using JSURL encoding, following the pattern: https://app.port.io/self-serve?action=ACTION_IDENTIFIER&actionInputs=ENCODED_INPUTS This mechanism does not extend to Workflows. Workflows currently have no equivalent shareable or pre-filled execution URL, and no dedicated link is attached to a workflow instance. Problem: Users who have adopted Workflows cannot: Generate bookmarkable or shareable links to trigger a specific workflow with pre-filled inputs. Embed workflow execution links in documentation or external systems. Use workflow URLs within entity properties (e.g., calculation properties) to trigger workflows in context — a capability that exists for actions. Proposed Solution: Introduce a URL scheme for Workflows analogous to the existing action URL pattern, supporting: A stable, shareable URL per workflow (e.g., https://app.port.io/workflows?workflow=WORKFLOW_IDENTIFIER ) Optional pre-filled input parameters via JSURL encoding Support for embedding these URLs in entity properties and calculation properties to trigger workflows in-context

Current State: The Action Card widget allows users to execute self-service actions directly from any dashboard or homepage. However, this widget currently only supports Actions & Automations — Workflows (Beta) are not supported as a widget trigger. Problem: Users who have migrated or are migrating to Workflows cannot surface them on dashboards or homepages the way they can with actions. This creates a gap in discoverability and usability for workflow-based self-service experiences. Proposed Solution: Extend the Action Card widget (or introduce an equivalent "Workflow Card" widget) to support triggering Workflows directly from dashboards, with the same UX as the current action card — including single and multi-workflow layouts.

Problem Without server-level instructions, the Port MCP Server lacks organizational context by default, leading to undeterministic responses, incorrect tool calls, and agents unfamiliar with internal terminology (e.g., "services" vs "artifacts"). Existing workarounds — Skills, custom prompts, and separate agents — all require extra distribution and setup friction that server-level instructions would eliminate entirely. Proposed Solution Allow platform engineers to define custom instructions at the MCP Server level that are: Injected as the first point of context on every interaction, bypassing the need for subsequent reasoning loops Configurable once via Port UI/API, applying universally to all developers without per-user setup Able to encode internal terminology, blueprint priorities, and organizational guidance Expected Outcome Consistent, terminology-aware AI responses across the organization Zero distribution friction compared to Skills or custom prompts Reduced need for developers to be explicit in every query

The default Port AI Assistant does not support a configurable system prompt. This causes inconsistent AI behavior across organizations — the AI may ignore org-specific docs, use incorrect tool calls for custom blueprints, or produce poorly formatted output for specific interfaces (e.g., Slack). Current workarounds (AI Chat Widget, custom Agents, Skills) are either scoped to specific dashboards or require manual user action, making them insufficient for org-wide consistency. Proposed Solution Add an organization-level default system prompt setting (e.g., under Organization Settings → AI) that allows platform engineers to: Override the default system prompt for the Port AI Assistant globally. Control which Skills are always loaded or excluded per interface. Define interface-specific prompts (e.g., web vs. Slack). Expected Outcome Consistent, context-aware AI behavior across all interfaces — without requiring users to manually select agents or craft explicit queries.

It will be helpful to add skills to an AI agent in port the same way we assign it with tools