Feature ideas

It would be great to have an AI assistant with the context of previous mappings created in Port that can help me create mappings for my blueprints for each exporter. Even if it won't be 100% precise, it could save me a lot of trouble and time. It can help with writing and creating the mapping independently (e.g., finding relations between entities natively).

Can Port support ingesting AWS costs from the Cost explorer API? https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/Welcome.html There is an official aws plugin for backstage that does this https://github.com/awslabs/backstage-plugins-for-aws/tree/main/plugins/cost-insights The link provided here is no longer valid. https://roadmap.getport.io/ideas/p/aws-exporter-support-cloud-resources-costs

Current scenario: Integrations are calculating the payload based on the mapping YAML, and they send all properties that are being mapped. Suggestion: Add the ability to drop the key in the mapping configuration. This way, the integration will not override existing keys in Port, while still having the ability to map data dynamically. Example: protected: if (.branch.protected != null) then .branch.protected else {DROP_KEY} end If the object contains the branch data, then map it to the entity, and if it does not a custom operation will drop the key from the payload, not overriding the current data.

We need the ability to pause and resume data source syncs. While we understand that rate limits determine the sync frequency, having the option to pause and resume would give us control over the order in which data sources sync. This capability is essential as we gradually roll out Port to different teams, ensuring their service data is accurately captured and reviewed before proceeding to the next team.

Today Port hosted integrations are working on a schedule-basis, and ideally it would be better to be able to create real-time integrations hosted in Port.

Today, you can see only whether the integration is syncing and when it was last synced. But it would also be helpful to understand to overall progress of each sync process

As a builder, I want to understand my integration status so I will be able to fix errors and keep my Portal up-to-date === We want to show a more apparent status and surface outstanding errors with the integration

It could be useful to use Port to visualize historical data. One example is if we have Dora metrics and tracked in a different tool already. It could be great migrating the data data to Port and utilize visualizations like a line chart.

Currently, each data source requires specific mapping configurations tied to the exporter / integration deployment phase. This approach is inefficient when managing multiple data sources. We propose implementing a centralized and versioned configuration in Port to improve this process. Proposal: Port will store a list of mapping configurations for each integration type. Each data source will have an option to specify which configuration version to use and whether to stream data into port or not. This will allow sharing configurations between different exporters of same integration. The process will decouple data source management from exporter / integration rollout. Benefits: Reduced configuration duplication Easier updates and maintenance Improved scalability for managing many data sources Consistent configuration across environments This feature aims to streamline data source management, making it more efficient for teams working with multiple data sources. --- ## Additional explanation based on k8s integration Today, each k8s cluster is represented as a separate data source without any control over shared configuration for all clusters, in addition k8s data source can't be created on demand and depends on deployment of k8s exporter. Each configuration change needs to be applied to all k8s data sources explicitly either via API/UI/Terraform or based on config-maps deployed on each cluster. After applying the proposed approach, port builders will be able define and share configuration among multiple k8s clusters and apply experimental changes gradually. How this could work in practice: every k8s exporter is deployed on each k8s cluster when it is supplied with appropriate credentials to access port and publishes only the cluster name. In addition the exporter subscribes to receive new instructions from port (which data to stream). port builders (developers) discover all k8s clusters associated to their account and choose which clusters should be enabled as data sources and which mapping configuration version should be applied. This way k8s exporters are deployed once and upgraded only when there is a new version of exporter. The control over data input is managed centrally from port and configurations can be shared among multiple data sources of same type.

As for now the user can only pass data of one file as a value to a property. But ingesting multiple files can be helpful in scenarios like markdown file where you can create links to other files. Example: [user docs](./userDocs.md)