Feature Requests

Enable direct Harness Platform (Delegate-less) connectivity for the Azure Key Vault Connector using Service Principal or OIDC authentication. Problem: The Azure Key Vault Connector currently requires a Delegate for connectivity. Because Harness Cloud build runners (e.g., Windows platform) cannot route through delegates, secret expressions (<+secrets.getValue(...)>) fail to resolve, returning raw ${ngSecretManager.obtain(...)} strings during execution. Goal: Achieve feature parity with AWS Secrets Manager, GCP Secret Manager, and HashiCorp Vault by allowing direct Harness Platform secret resolution on Harness Cloud builds.

Today an IaCM workspace uses a single provider connector for every step in a stage. Overrides such as PLUGIN_CONNECTOR_REF , set either on an individual step or as a stage-level variable, are ignored. Teams that follow least-privilege practices want Plan to run with a read-only cloud role and Apply to run with a write-capable role, but cannot do that on one workspace. Workarounds are to run both with the write-capable identity, to split into two workspaces with separate state that must be kept in sync, or to use a base role that can assume both roles. Please let a workspace use a different connector or role for Plan and Apply (for example a connector per operation, or honoring a step-level or stage-level connector), while sharing the same state. This matters for organizations rolling IaCM out broadly, where security review often blocks giving the planning step write access to cloud accounts.

We have an audit need to attach items to our servicenow ticketing system. This is supported by the API but not harness native steps. while a scripted workaround is possible, it creates a burden on our developers.

Summary: Bitbucket Cloud has deprecated app passwords (EOL June 9, 2026). Harness currently requires a username + password (historically an app password) for Bitbucket Cloud connectors, which prevents authentication using the new Workspace-level API Tokens. Use Case / Problem Statement: When configuring a Bitbucket Cloud connector, entering email/username + Workspace API Token fails authentication. The connector enforces the legacy password path, which is no longer aligned with Bitbucket’s new authentication model. Impact: Blocks onboarding for Bitbucket Cloud users who can’t generate app passwords. Prevents IDP workflows that temporarily modify repo permissions (e.g., bypass branch protection, commit, and revert). Creates compliance and migration risk as app passwords near deprecation. Proposed Enhancement: Add native support for Workspace API Tokens in the Bitbucket Cloud connector. Allow token-only or username + token authentication modes. Update connector UI to include an “API Token” credential type distinct from “Password/App Password.” Ensure parity with Bitbucket REST API validation behavior. Expected Outcome: Harness users can authenticate Bitbucket Cloud connectors with Workspace-level API Tokens, ensuring continued compatibility and compliance with Bitbucket’s new authentication model.

Summary Add a configurable retention (TTL / auto-expiry) policy to the Harness IDP custom integration, so entries ingested through it are removed automatically after a set period. Customer context A customer recently went live with a Jenkins custom integration. Their only feedback after go-live was that the custom integration has no built-in way to expire old data. Problem Entries pushed through the custom integration accumulate indefinitely. To keep the data clean, the customer built and now maintains a separate scheduled pipeline whose only job is to delete old entries. Current workaround A standalone pipeline scheduler that periodically finds and deletes stale entries. This works, but it adds: an extra pipeline to build, run, and monitor custom deletion logic that has to be maintained a risk of stale data lingering if the cleanup job fails or is misconfigured Requested behavior A retention setting on the custom integration (e.g. “delete entries older than N days”), configurable per integration. Age is measured from the entry’s last update or ingestion timestamp (the option to choose which would be ideal). Expired entries are removed automatically, with no external pipeline. Default is “no retention” so existing integrations are unaffected. Nice to have Different retention periods per entry type or per integration. An audit log or event when entries are purged. A dry-run or preview of what would be deleted. Business impact Removes the need for a separate cleanup pipeline. Keeps IDP data accurate, since stale CI/build data won’t show up in the catalog or scorecards. Lowers operational overhead for any customer using custom integrations.

When a parent entity is created on a base branch and references a child entity in the same repo on the default/same branch, we currently omit the child entity’s branch from the parent YAML. If the parent is later saved to a new branch, that omitted value becomes a problem: at runtime the child can be resolved from the parent’s new branch instead of the child’s own default/feature branch. Request: Let users optionally force-save the referenced child entity’s branch in the parent YAML, so the child continues to resolve from its intended branch even after the parent moves to a different branch.

When an IDP backend proxy endpoint calls an internal service through a Delegate and a header uses a secret, the target currently receives two requests per click. The first is a connectivity check that carries the unresolved secret expression instead of the secret value, and the second is the real call with the secret resolved. If the target rejects the first request, it shows up as a spurious error in the target's logs, and the secret expression string reaches a service that should never see it. Please send the connectivity check without the unresolved secret headers. That would keep the expression out of the target's logs, avoid the noisy errors, and let repeated calls to the same target reuse the earlier check instead of sending an extra request each time.

Currently when a developer has a pipeline and it fails, its nearly impossible to do the calculation to see why the pipeline is failing due to over provision for resources. There should be a easy way before building to see how much cpu and memory that the pipeline is going to request. This will save the times where we see jobs not able to run and pods getting evicted for Harness SMP to run the build.

In order to support BitBucket authentication for user accounts and the upcoming deprecation of App Passwords, we would like Harness to support API token authentication as advised by Bitbucket: https://www.atlassian.com/blog/bitbucket/bitbucket-cloud-transitions-to-api-tokens-enhancing-security-with-app-password-deprecation Please provide us this new feature so that we can continue to utilize our connectors.

In Directed Acyclic Graph (DAG) pipelines, where stages are linked by dependencies and can run in parallel, any stage can be chosen in "Re-run From Specific Stage" or "Retry Failed Stages". If a downstream stage is selected on its own, the stages before it are replayed from the previous execution, so it consumes stale outputs and variables from upstream instead of fresh ones. For pipelines with many cross-stage dependencies, this can produce inconsistent or invalid runs. We'd like a setting in the pipeline or template configuration (for example a "Re-run Settings" section under Advanced Options) to define which stages are allowed as re-run or retry starting points. Stages not on the list would be disabled or hidden in the re-run dialogs. Today RBAC and OPA can't enforce this, and the only related ideas disable re-run entirely, which is too coarse when some stages are safe to restart and others aren't.