Feature ideas

The GitHub Ocean integration currently fetches team data via GitHub's GraphQL API but does not include parentTeam or childTeams fields. We'd like these fields to be added to the integration's team query so that team hierarchy relationships (parent/child) can be mapped into Port, for example, via a self-referencing relation on the githubTeam blueprint.

Add a configuration option to allow live event (webhook) handlers in Ocean integrations to process mapping kinds sequentially (mirroring the behavior of the periodic sync) in order to ensure consistent entity and relation building for users with cross-blueprint dependencies. Live event behavior and periodic sync behavior should be configurable to match, giving users confidence that their data is consistently built regardless of the ingestion path.

Ingest vulnerabilities from Prisma Cloud for open source, containers and other sources

As per the the title, add live events to the Dynatrace integration

Per the title, add support for live events for the Port-Hosted Terraform Cloud integration. Currently this is supported in the self-hosted but not the Port-Hosted

Per title, add release and release deployment live events to the ADO integration

A native Gemini integration transforms Port from a static directory into a proactive development partner, using the Catalog's metadata as its "brain" to track usage metrics, licensing as well as adoption of Google Gemini

As a security engineer, when I access Port I would like to see more information relating to the Ignores with details about duration, comments etc

Add support in the ArmorCode integration to pass filters.status in the POST body of /api/findings requests, based on the mapping/selector configuration, instead of applying status filters only client-side in Port. Concretely: When a selector filters findings by status (e.g., OPEN , IN_PROGRESS , CONFIRMED , TRIAGE ), translate that into a filters.status array in the ArmorCode request body. Ensure this is applied for all paginated /api/findings calls. This will help reduce API calls made against the Armorcode API

Problem The Event Log is difficult to use for troubleshooting: No severity filtering in the UI (only available via API) No way to navigate from a step directly to its logs Partial failures are not visually distinguished from full success Log history capped at 1,000 entries with limited search Requested Improvements Severity filtering in the UI, filter by INFO, WARNING, ERROR, etc., with the option to suppress noisy info logs Step-level log navigation: click a step to jump directly to its logs Partial success indicator: visually distinguish partial success from full success/failure Download logs: export logs for local searching Timeframe selection: filter logs by time range