Feature ideas

We want to be able to have a backup for all the port organization and the entities. This should allow us to have a backup running every X hours and save a file with the information to allow us to recover entities and configuration in case of mapping issues or any other need to restore data to port.

Currently, there is no "Select All" or "Deselect All" option available for array-type entity inputs in self-service action forms, requiring users to manually select each item one by one — which becomes tedious and time-consuming when dealing with large lists. We'd like to request the addition of a "Select All" / "Deselect All" toggle or checkbox at the top of array-type entity input dropdowns, so users can bulk select or deselect all available items with a single click, significantly reducing friction and improving usability for anyone working with large arrays in self-service action forms.

Having access to the Port MCP within the m365 Copilot ecosystem would be immensely valuable for management tasks: querying a list of services for a spreadsheet to organize a compliance review, getting a list of email addresses for service owners of all .NET services within a specified division of the company for a targeted email message, etc. Providers can submit their MCP servers to be listed in the connectors gallery for m365 Copilot tenants here: https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/submit-federated-connector

Background When an Ocean integration starts up, it reads its mapping from .port/resources/port-app-config.yml and applies it to the integration config stored in Port. However, this only happens in two narrow cases: when the integration is being created for the first time, or when it exists but has never been initialized (empty config). In both cases, patch_integration() is called with the port_app_config payload. Once the integration is fully initialized, Port sets arePortResourcesInitialized = true on the integration record. From that point on, every subsequent restart hits an early-return guard in BaseSetup.setup() and skips the entire setup phase. Only metadata fields ( changelogDestination , version , actionsProcessingEnabled , processingMode ) are ever updated via _verify_integration_configuration() - the mapping is never touched. This is intentional: it protects mappings that users may have edited manually in the Port UI from being overwritten on redeploy. Problem The protection has no opt-out, which creates a real friction point for integration developers who manage their mapping in code and expect port-app-config.yml to be the source of truth. In practice this means: Updating the mapping in port-app-config.yml and redeploying silently has no effect - the old mapping keeps running. Running a new version of an integration alongside an outdated mapping is not immediately obvious and can produce confusing behavior. Developers are forced to manually clear or reset the mapping in the Port UI to pick up changes, breaking the "ship code + mapping together" workflow. Proposed Solution Introduce an opt-in configuration flag (e.g. overwrite_config_on_restart , analogous to the k8s-exporter's overwrite-configuration-on-restart ) in IntegrationConfiguration. When enabled: The arePortResourcesInitialized guard in BaseSetup.setup() should not short-circuit. _verify_integration_configuration() (or the setup flow) should call patch_integration(port_app_config=...) with the mapping loaded from port-app-config.yml . The flag should default to false so existing behavior is fully preserved for production deployments where users manage their mappings in the UI. Notes This mirrors a pattern already established in the k8s-exporter ( overwrite-configuration-on-restart ), so there's prior art in the product for this kind of escape hatch. The fix is low-risk when scoped correctly, the default-off behavior means no existing integration is affected unless the flag is explicitly set. A follow-up consideration: whether to expose this flag via an env var, a Helm value, or both, to cover different deployment models.

Enable AI agents to use tools from MCP connectors in automated workflows. A current workaround is to import data into the Port catalog, but this removes real-time access. Adding MCP connector support to agent workflows, with the same RBAC and audit controls, would allow more useful and flexible use cases.

Description: Currently, the Runs tab in the audit log does not expose approver details as a filterable column. It would be very useful to: Display the assigned approvers and who actually approved a run as columns in the Runs table Allow filtering by approver directly in the UI, without needing to query the API (GET /v1/actions/runs/:run_id/approvers) for each run individually This would improve traceability and auditing of approval workflows significantly.

Description: > Add an "Admin Override" toggle to the core approval settings for Self-Service Actions (SSA) and workflows. Key Capability: > Allows Port Admins to intervene and instantly approve any pending request manually. When the override is used, it skips all remaining approvals in the sequence and immediately marks the workflow as approved.

Add official support for AWS GovCloud environments in AWS integrations. At present, customers operating in GovCloud experience failures because the integrations assume standard commercial AWS ARN formats and depend on AWS APIs that are not available in GovCloud regions.

Today when adding a mulit-chart line with property history, you MUST pick a single static entity for it. However, I'd rather select a blueprint and provide a filter criteria for choosing multiple entities to chart with the selected aggregation or other property and each entity shows up as a separate line. This could show up to a max of entities (as lines). This enables you to more dynamically show aggregation history on a subset of data.

When a self-service action is in WAITING_FOR_APPROVAL status, both the approver and the requester should be able to exchange messages/comments directly within the action run context in Port. This would eliminate the need for out-of-band communication (e.g., Slack DMs) and keep all context in one place. It would also reduce the friction of having to decline → resubmit cycles just to clarify inputs.