Feature ideas

Request for a top-level onWorkflowFailure handler, or a reserved finally branch on workflow definitions. Today, there's no way to reliably trigger a notification (Slack, PagerDuty, etc.) when a workflow fails without compromising the workflow's final status. The current options available are: onFailure: terminate — correctly marks the workflow FAILED, but downstream notification nodes never run. onFailure: continue — notification nodes run, but the overall workflow is marked SUCCESS despite the upstream failure. Impact: Can't easily implement basic alerting without misrepresenting operational health.

When triggering webhooks or direct orchestrator calls from Port Self-Service Actions or Workflows, Port currently requires secrets (API keys, tokens) to be stored within Port itself. For organizations with strict infosec policies — where all secrets must reside exclusively in HashiCorp Vault — this is a blocker. The workaround today is to route through a CI system (GitHub Actions, Jenkins, etc.) that handles the Vault key exchange, but this introduces an unwanted dependency for teams using a direct orchestrator pattern where the orchestrator feeds execution feedback back into Port. Requested Capability: Native support for HashiCorp Vault as a secrets backend for Port Actions/Workflows — allowing Port to resolve secrets at runtime from Vault rather than storing them locally. Use Case: Customer: Sophos (via Nuno Pinto) Trigger: Self-Service Action → direct webhook/orchestrator call requiring authenticated API keys Constraint: Infosec policy mandates all secrets stored in HashiCorp Vault only Current gap: No native Vault secrets resolution; CI workaround not viable for their direct-trigger architecture

Here's a concise feature request that frames the customer impact rather than just the implementation detail: Update Datadog Integration to API v2.2+ (Support Service Catalog) ## Problem Port's Datadog integration currently relies on an older version of the Datadog API. As customers begin investing more heavily in Datadog integrations, this is becoming a significant limitation—particularly for ingesting data from the Datadog Service Catalog, which depends on newer API capabilities. ## Customer Impact * Blocks Service Catalog ingestion from Datadog. * Prevents customers from leveraging newer Datadog platform capabilities. * Forces workarounds or custom integrations for modern Datadog deployments. * Makes it difficult to fully adopt Port as the engineering catalog when Datadog is a primary source of truth. ## Requested Enhancement Upgrade the Datadog integration to use the current Datadog API (v2.2+), enabling support for Service Catalog ingestion and other modern API capabilities. ## Customer Context A customer recently began implementing the Datadog integration and immediately encountered this limitation. Their observability engineering team is now involved, and this is expected to become a key discussion point as they expand their Datadog usage. ## Success Criteria * Datadog integration supports the latest stable Datadog APIs. * Service Catalog entities can be ingested into Port. * Future Datadog capabilities can be adopted without requiring a major integration rewrite. This version is likely to get more traction internally because it focuses on customer value and business impact , not just "please upgrade the API." It also avoids locking the engineering team into a specific API version while still making the need clear.

Add native support in the GitHub Ocean integration to enrich githubUser entities with email addresses sourced from organizationVerifiedDomainEmails

When a workflow webhook node retrieves a dynamic credential (e.g., an OAuth access token) at runtime, the full response including the token is stored in variables.outputs and is permanently visible in the workflow run history UI for up to 90 days. There is currently no way to mark a variable as sensitive so that its value is redacted or masked in the run history display. This is a security concern for any workflow that must fetch short-lived credentials dynamically, as Port Secrets (the recommended alternative) only support static, non-expiring values.

The team field is silently ignored when included in a POST /v1/workflows request body, making it impossible to assign team ownership to a workflow at creation time via the API. This is a confirmed feature gap, team is not currently a supported top-level field on the Workflows API, even though ownership can be set manually via the UI. Support the team field on POST /v1/workflows and PUT /v1/workflows/:id, consistent with how team works when upserting catalog entities. Document the team field explicitly in the API reference.

We are looking to sync ServiceNow incidents and requests near-real-time via ServiceNow Business Rules that POST outbound webhooks to Port Ocean's webhook event listener on record create/update. Port's ServiceNow OOB integration's webhook event listener currently has no mechanism to verify that an incoming payload actually originated from our ServiceNow instance — there's no signing secret / signature header support. This is required for the ServiceNow integration for verifying the source.

After a GitHub Actions node runs, downstream nodes cannot access its conclusion. While the workflow run API exposes result: FAILED on the node run object, the .outputs available to downstream JQ expressions only include workflowRunUrl and workflowRunId, not result, workflowStatus, or any error detail. This creates a dead end: the information exists in Port's data model, but it's not reachable from within the workflow itself. result, workflowStatus, and error should be surfaced in .outputs["<node_id>"]

The file kind currently only supports a positive files.repos allow-list, requiring the platform team to manually add every newly onboarded repo before its port.yml is picked up. Going allow-list-free (group-wide search) is the desired end state, but the we need a way to exclude repos we do not intend to ingest. The request is to add an exclude/skip-repos option to the file kind config so the we can search broadly across a group or org while excluding specific repos.

Currently, custom widgets only allow HTTPS links. Any attempt to use a custom URI scheme (deep link) is blocked, and the browser console displays: Requested Enhancement: Support custom URI schemes in custom widgets by allowing administrators to configure or whitelist approved protocols (e.g., cursor://, claude://, claude-cli://, codex://) instead of restricting links to HTTPS only.