Feature ideas

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.

The request is to allow each organization within a multi-org setup to support a separate SSO connection.

We want to be able to create a new org in our multi-org structure using the API and not the UI in the app.

Today a lot of platform engineering teams track regularly how many users logged on, from which teams, when etc... This is to measure usage and adoption. Port customers have that info available through a different link but it would be easier to have it directly in Port, for example in the Audit or in an admin tab. Or even as a user property ("last login") which would give the capability to aggregate and create dashboards.

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

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.