Feature ideas

Currently AWS v3 supports a closed list of kinds. whenever a customer requests a kind that is not supported, it requires Port's team to add it to the integration. We would like to allow customers add any kind they need easily similarly to the previous AWS integration (v2)

To be able to fully test mapping before applying it or running a resync, we would like to expose all examples from the integration raw data with the ability to filter by specific field value from the example json.

Replace raw JSON configuration with a visual UI for building and editing workflow nodes, making workflows faster to create and easier to understand.

Add granular permission controls for who can create and edit workflows, with support for service accounts as a mechanism to scope workflow execution and authorship to approved identities.

Add live events support for the following in the Github Ocean Integration: team: removed_from_repository membership: removed (for collaborator kind - it is already handled for team kind) pull requests: pull_request_review , assigned , review_requested , converted_to_draft , locked , unlocked , auto_merge_enabled , auto_merge_disabled , milestoned , demilestoned , dequeued , enqueued , stacked organization: deleted , renamed , member invited , member added , or member removed

Request to add first-class support for the AWS::RDS::DBCluster resource type to the AWS v3 integration so ElastiCache clusters can be ingested as their own kind and mapped into Port blueprints. The feature should expose key ElastiCache cluster attributes so they can be mapped into a dedicated blueprint and used for catalog relationships and scorecards.

Per title, integrate with Tenable Cloud

Enable users to roll back an integration's mapping to its previous version in one click. When a mapping change causes issues, whether the new mapping is wrong or the resulting data in the portal no longer reflects what the user wants, they currently have to manually track down and reverse each change to get back to a working state. Instead, they can select roll back and the previous mapping is restored and reapplied using the existing apply mapping mechanism, re-syncing the data to the last known good state with no need to track or undo the changes manually.

Port currently only supports generic OpenAI-compatible providers. When customers need to use an Anthropic API-compatible provider (e.g. to proxy AWS Bedrock Claude models), the OpenAI chat completions path does not fully support the Anthropic Messages API schema, leading to validation and runtime failures. A dedicated Anthropic API-compatible provider type would allow customers to correctly route requests through their chosen proxy to Anthropic/Bedrock without hitting schema incompatibilities.