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.

I've been trying to set self-service action input defaults on team, array, and string inputs based on properties of the current user or the action's triggering entity. I went through a lot of AI-suggested attempts, but nothing worked. For instance, I have a self-service action that triggers a GitHub Actions workflow to create a git repo. There's an input to choose the team that should be added to the repo with admin privileges, but there's no way to default the team input to, say, the first team in the user's team list. I tried using default as shown below, but it doesn't do anything (I also tried .user.teams[0].name ). It seems that default only supports a static string. "github_admin_team": { "type": "string", "title": "GitHub Admin Team", "icon": "DefaultProperty", "format": "entity", "blueprint": "_team", "sort": { "property": "$title", "order": "ASC" }, "default": { "jqQuery": ".user.teamIdentifiers[0]" } }, I have another workflow to manage users on a team. I spent several hours going back and forth with the AI model trying many different strategies, but none could give me a pre-filled input with the list of current users that I could edit with a user dropdown. I ended up creating an add/remove toggle, and showing a different input for each mode. For removing users from a team, the best I could do was create an unpopulated input and let the operator pick from an unsorted list of every user in the org to build a removal list. "user_remove": { "title": "Users to Remove", "description": "The users to remove from the team", "dependsOn": [ "team", "action" ], "visible": { "jqQuery": ".form.team != null and .form.action == \"remove\"" }, "type": "array", "items": { "type": "string", "format": "user" } }

Add OPEN_AI_CHAT postMessage event type to allow custom plugins to trigger the AI Assistant sidepane with a pre-populated prompt Description: Extend the Port plugin postMessage API with a new event type that allows a custom plugin to programmatically open the AI chat sidepane and optionally pre-populate it with a prompt. Proposed message shape: { "type": "OPEN_AI_CHAT", "data": { "prompt": "Analyze the DORA metrics for this team and summarize change lead time trends.", "agentIdentifier": "dora_metrics_agent" } } prompt (string, optional): Pre-populated message to send or display in the chat input. agentIdentifier (string, optional): If provided, opens the chat scoped to a specific AI agent. If omitted, opens the general Port AI assistant.

In order to improve adoption, key point is around branding, being able to use port ( even saas ) via a custom domain like port.mydomain.com , or dev-portal.mydomain.com can help tremendously on internal adoption

Input-level dataset filters and required field validations in Self-Service Actions are currently UI-side only. Any execution path that bypasses the form UI, JSON mode, direct API calls, or Port's MCP, skips these validations entirely, allowing invalid or unauthorized inputs to be submitted. The desired behavior is for all execution paths to respect the same validation rules defined in the form UI, with meaningful error messages returned on violation. Current workarounds are insufficient for all cases: Dynamic permissions: server-side enforcement, but requires manual policy configuration per action. ownedByTeam: true on blueprint read permissions, restricts entity visibility at the catalog level, but does not cover all use cases.