Feature ideas

Out-of-the-box support for multiple Linear workspaces under a single integration instance.

Currently, when users authenticate via Entra ID OIDC SSO, Port ingests all groups returned by Microsoft Graph, including both Security groups and Microsoft 365 (Unified) groups . Port's existing SSO group filtering only supports regex matching against group display names. Requested Capability Add an option in the SSO Group Filters configuration to filter groups by their Entra ID group type: Allow syncing Security groups only. Exclude Microsoft 365 / Unified groups from being ingested as Port teams.

Currently OCEAN__METRICS__ENABLED and OCEAN__METRICS__WEBHOOK_URL can't be set on port hosted ocean integrations. This makes this guide: https://docs.port.io/guides/all/monitor-integrations/ not possible on such integrations. There should be an easy way to set this up in the UI. (Really what I want is automatic creation of an entity on each sync, perhaps there could be a simpler way to achieve this)

Request to support dragging and moving nodes around within the workflow editor to our desired position. For example, when editing a WF in a smaller laptop screen, I may want to move the nodes to be closer together to see them all at once. Another positive addition for customization would be the ability to flip the workflow from being displayed horizontally to vertically.

Port CLI skills sync/add only reads literal entity.properties .references. If references is a calculationProperty (e.g. zipped from mirror properties sourced via a relation to child skill_reference entities), it's silently skipped — only SKILL.md downloads, no error or warning. Confirmed by Port support as a known limitation. Modeling reference files as related entities (one per file, vs. a single inline array) is a natural, common pattern — anyone using it gets silently incomplete syncs. Repro: Skill with references as a calculation property (zipped from mirrors of related skill_reference entities) → port skills sync --skill <id> → SKILL.md downloads, references/ doesn't, no error. Ask: Port CLI skills sync/add resolve references/assets from the entity's full computed value, not just literal properties.

Port's ingestion webhooks currently authenticate incoming requests only via a static shared secret validated through HMAC signature checks. This leaves no way to issue short-lived, revocable credentials for webhook senders, which is a blocker for organizations with strict IAM policies against long-lived static secrets. Add support for validating an OAuth 2.0 access token (e.g. client_credentials grant) on inbound webhook requests, used alongside the existing HMAC check rather than replacing it. Without this, security-conscious customers can't onboard ingestion webhooks at all under their compliance requirements.

Today you can manage permissions on a Page, Self service, and blueprint level. Since some IDPs can have multiple "Builder" teams in different business domains, it would be ideal to have the option to define for each data source who has permissions to view the mapping, and modify it.

Field tooltips in self-service action forms and blueprint properties currently render as a single line of plain text. There's no way to add line breaks, bullet lists, or emphasis (bold/inline code), which makes it hard to explain non-obvious fields clearly — naming conventions, required formats, "don't do X" warnings, or an example value.

Our custom plugin widget renders format: "markdown" properties, including text and code, but not images. Images uploaded via Port's markdown editor are stored on asset.us.port.io behind CloudFront signed URLs. The only way to get a signature is GET /v1/asset/download-signature, but its CORS allowlist doesn't include our plugin iframe origin ( https://us.portwidgets.io ), so the browser blocks the request.

We would like to import into Port all the Network Interfaces (AWS::EC2::NetworkInterface). We are especially interested in the public IP address of the network interface. Note that unfortunately it is not return via the CloudControlAPI from AWS but it is return via the AWS API. This will allow our cyber security team to have an inventory of all publicly facing network interface, and also our devop team to quickly identity in which account a resource is when they only get an ip address in a ticket.