Feature ideas

The "Set up your portal" activation checklist evaluates the "Connect your tools" items (Git provider, Project management, Code quality & security, APM & alerting, Incident management) automatically — a step only resolves isDone when an active integration for that category is configured, with no manual override. Admins who intentionally have no plans to use a specific integration category (e.g., Incident Management) are permanently stuck with an incomplete checklist panel showing e.g. 4/5 done, and the only way to clear it is to install an integration they don't need. Adding a per-item dismiss or "not applicable" option would let admins reflect their actual setup intent and remove persistent UI noise for orgs with deliberate integration gaps.

Port currently requires manual credential rotation for organizational client_id and client_secret: Organization admin must log into Port UI Navigate to Credentials settings Manually generate new credentials Copy/paste credentials into CI/CD secrets, environment variables, documentation Manually update all dependent systems simultaneously No audit trail of when rotation occurred or who initiated it Business Impact Many organizations operate under compliance requirements (SOC 2, ISO 27001, HIPAA, FedRAMP, internal security policy) that mandate credential rotation on a periodic basis: "All API credentials must be rotated every 90 days" "Service account passwords rotated quarterly" "Programmatic access tokens refreshed biannually" Without an automation-friendly API, the organization is forced to: Schedule manual rotation tasks (e.g., quarterly calendar reminder) Perform manual UI operations at scheduled intervals Coordinate updates across all systems using those credentials Document rotation in compliance logs manually Handle timezone/scheduling complexity across distributed teams Result: Compliance teams view Port integration as operationally burdensome Relationship friction with customer due to perceived lack of operational maturity Risk of rotation being skipped or delayed due to operational overhead No programmatic audit trail for compliance auditors Inability to implement progressive rotation (old/new credential overlap) Why This Matters The organization doesn't need per-application credentials yet (Scenario 2). They need a simple, automatable way to rotate their single organizational credential pair on a schedule, integrated into their existing credential rotation automation (e.g., HashiCorp Vault, AWS Secrets Manager, custom rotation tooling).

When an MCP connector uses shared/static-header auth, users should be automatically connected without a manual "Connect" step. Admins should be able to mark such connectors as auto-connected for all org users.

Add Daily and weekly usage metrics and feature-level usage data to the Usage Dashboard, including total accesses and unique users per feature

Please add support for Amazon Bedrock API keys as a native authentication method alongside the existing assume-role and static IAM access key options. AWS now supports service-scoped Bedrock API keys (both long-term and 30-day short-term). Allowing users to store a Bedrock API key as a Port secret and authenticate directly via the AWS_BEARER_TOKEN_BEDROCK mechanism would remove the need for cross-account roles or broad IAM keys. This significantly reduces the security blast radius and simplifies credential rotation.

Add the ability to filter the Usage Dashboard by Organization and Team, with an option to exclude specific teams from the metrics. This would allow customers to exclude their Platform team, whose high level of activity can skew adoption data, and instead measure the actual usage of Port across their engineering teams. This would provide more accurate adoption insights and improve reporting for customers.

Problem Statement The Usage Dashboard provides a valuable high-level view of Port adoption, but it is difficult to use for deeper product and UX analysis due to limitations in export structure, available dimensions, and analytical depth. Requested Improvements Unified, Structured Export A single export (CSV or Excel) covering multiple widgets or the full dashboard tab, with consistent columns across widgets, rather than separate per-widget exports with varying schemas. Filterable Dimensions in Exported Data Exported files should include key dimensions as columns, such as: Organization Time period User role (member vs. admin) Team Page title Action title Blueprint or feature category Behavioural Analytics Incremental additions to support product and UX analysis: User journey / path analysis: how users navigate between pages or actions sequentially Funnel and conversion tracking: where users drop off in multi-step flows Event-level granularity: individual events with properties such as role, team, feature area, and entry point Session-based views: time between steps, repeat visits within a session, and common sequences before or after key actions Why It Matters These capabilities would allow product and UX teams to make data-driven decisions about onboarding, feature adoption, and navigation without needing to export raw data to external analytics tools for every analysis.

On a fresh Port org, terraform apply fails or conflicts with live state because out-of-the-box (OOTB) objects (blueprints, pages, scorecards) are pre-created and must be manually imported before Terraform can manage them. There is no documented canonical inventory or tooling to automate this process. Problem When a customer starts managing a new Port org with the Terraform provider, they immediately encounter conflicts because OOTB resources (e.g., port_blueprint.service, port_ blueprint.team , port_page.home) already exist in the org but are not in Terraform state. This forces a manual, error-prone import process for every environment. Compounding this, OOTB resource sets differ between orgs created at different points in time (due to Port's active development), causing drift between environments and forcing customers to maintain env-specific import files and conditional branches in shared Terraform modules. There is currently no documented greenfield org inventory, no ready-made import blocks, and no tooling to automate the bootstrap process. Current Behavior terraform apply on a fresh org fails or fights live state due to pre-existing OOTB resources. Customers must manually identify every OOTB resource and run terraform import for each one before normal Terraform operations are possible. No canonical list of OOTB resource IDs or ready-made import blocks is published. No CLI tooling exists to emit import IDs or HCL skeletons for an existing org. Expected Behavior / Ask Publish a canonical greenfield org inventory — a documented, versioned list of all OOTB resource IDs (blueprints, pages, scorecards, etc.) with ready-made Terraform import blocks. Provide a bootstrap/export CLI — a tool that inspects an existing Port org and emits: Import IDs for all existing resources. HCL skeleton resource blocks ready to paste into a Terraform module.

We want to be able to have a backup for all the port organization and the entities. This should allow us to have a backup running every X hours and save a file with the information to allow us to recover entities and configuration in case of mapping issues or any other need to restore data to port.