Feature ideas

We are using search-based in github ocean integration and when there are more than 100 results we get Error: Audit: CREATE on githubTeam/{id} - Too many entities found for query of relation members We want to increase the number of returned entities to at least 500 so we could use this. Why search-based: We need resilience to non-existent member entities (createMissingRelatedEntities = false). Direct array mapping fails the entire team entity if any member's githubUser entity doesn't exist.

At present integrations do not support body parameter based, when using the custom Ocean integration calling APIs such as the GitLab graphql API is not currently possible as the cursor value cannot be passed back into the next request body as is standard within the "Relay Cursor Connections Specification" The ask is to allow extracted body values to be passed into the next request to enable cursors to work when located within the request body. Thanks

Add an option of mapping integrations using a UI interface instead of a Yaml. The new UI should reduce friction points such as: Understanding the page layout and how to use different components Search for information in Port docs, to understand mapping and extraction capabilities. Search for information in 3rd party docs. Understanding Port’s Yaml structure Moving between tabs copying and pasting. (data model discoverability) Typos and syntax errors

Port currently lacks a heartbeat functionality for data sources. This makes it difficult to distinguish between active data sources with functioning exporters and those without proper configuration or deployment. We propose implementing a heartbeat feature to address this issue. Proposal: Implement a heartbeat mechanism for Port data sources. Data sources will send periodic heartbeat signals to Port. Port will monitor these heartbeat signals. Port will display the active/inactive status of data sources based on heartbeat reception. Benefits: Clear visibility of data source status (active vs inactive) Easy identification of data sources with deployment or configuration issues Improved data source management and maintenance Enhanced system reliability and troubleshooting This feature will enable users to quickly identify inactive data sources, allowing them to either remove them from Port or address exporter deployment issues, thus improving overall system health and data accuracy.

Currently, the mapping modal, shows only kinds and examples that are mapped in the mapping yaml. Customer can't know which other kinds are available without looking in the docs. We would like to add to the kinds examples all kinds that are supported in the integration, even if they aren't mapped by default/ by a customer

Add option to specifically resync a predefined list of resources & do a scheduled resync only for a selected list of resources

Currently, we map the deployment status from the Deployment kind. It would be great if we could support Deployment Status as a separate kind.

We want to have the ability to map the entity identifier using a query search like the following mapping identifier: combinator: '"and"' rules: - operator: '"="' property: '"$blueprint"' value: '"_user"' - operator: '"="' property: '"$identifier"' value: '"\(.user_handle)@ github.com "' - operator: '"!="' property: '"port_type"' value: '"Service Account"' At this time this returns an entity and the custom ocean mapping give us a "identifier must be a string" error

Admins should be able to leave comments in the data source mapping.

Enable users to validate integration setup before full installation by testing connectivity, access, and basic permissions. Reduce setup errors and improve user confidence in integration correctness during onboarding.