Feature Requests

Add "domain" as an available attribute option in the "Bucket targets by" dropdown for percentage rollout variations in Feature Flags. Current Behavior: The percentage rollout feature currently supports bucketing by the following target attributes: Identifier (default) Name location These options appear in: The "Bucket targets by" dropdown in the flag variation configuration The Target Group Criteria modal when defining targeting rules Desired Behavior: Add "domain" as an additional bucketing option alongside the existing attributes (Identifier, Name, location). Use Case: Many organizations structure their targeting based on domain/tenant identifiers, especially in multi-tenant SaaS applications. Being able to bucket by domain would enable: Consistent Feature Distribution Across Tenants: Ensure all users within a specific domain/tenant receive the same variation, which is critical for B2B SaaS applications where feature consistency within an organization is important. Domain-Level Progressive Rollouts: Gradually roll out features to different customer domains/organizations rather than individual users, reducing risk and simplifying rollback scenarios. Better Alignment with Business Structure: Many enterprise customers are organized by domain/tenant, making this a more natural bucketing dimension than individual user identifiers. Example Scenario: A SaaS platform wants to roll out a new dashboard feature to 30% of customer organizations (domains) rather than 30% of individual users. With domain-based bucketing, all users within selected domains would see the new feature, while all users in other domains would see the existing version. Benefits: More flexible targeting options for multi-tenant applications Better control over feature consistency within organizations Reduced complexity in managing feature rollouts for B2B scenarios Improved customer experience by ensuring organizational consistency

Currently Harness input variables only support "hard coded" allowed values. It would be useful if an input's allowed values can be linked to a harness entity. For example if I have an input for "secret", instead of hard coding a list of secret IDs I should be able to "link" allowed values to <+project.secrets.type("text")> Similarly for connectors <+project.connectors.type("artifactory")>

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.

We are trying to integrate an external artifactory account with our Harness CI/CD pipeline. The external party wants to authenticate our pipeline using OpenID Connect (OIDC). However, the current Artifactory connector does not support OIDC for authentication, which limits our integration capabilities with OIDC-compliant identity providers. It would be beneficial if the Artifactory connector could support OIDC authentication to streamline our integration process.

The Azure OIDC Connector needs a federated identity credential to be set up on Entra side . This setup needs a subject identifier which right now should match the harness account identifier which is part of the harness url and is accessible to anyone who has access to the url . The ask is it make the subject identifier more specific and to include project indentifier and pipeline identifier so that the security posture can be improved.

With NGINX Ingress deprecated in SMP (through 0.45.0, removed as supported at 0.46.0) and Envoy Gateway becoming the supported ingress via the Kubernetes Gateway API, teams that relied on per-team Ingress self-service lose a clean way to manage their own listeners and TLS certificates. The Gateway-native replacement for that pattern is the ListenerSet (XListenerSet, GEP-1713), and it is not currently supported by the SMP-bundled Gateway API stack. Current state On SMP 0.44.x, XListenerSet resources are not reconciled by the bundled ingress. In practice this means all listeners must be defined centrally on the Gateway resource, there is no delegated, namespace-scoped listener or TLS self-service, and teams remain subject to the Gateway's single-resource listener model and its historical 64-listener limit. Desired behavior SMP should allow ListenerSets to attach to Gateways managed by the bundled Envoy Gateway. Specifically: install the experimental-channel Gateway API CRDs (or provide a supported toggle to do so), reconcile XListenerSet such that resources reach Accepted/Programmed, expose the Gateway's allowedListeners namespace scoping through chart configuration, and let HTTPRoute reference listeners defined in attached ListenerSets. Because the resource is currently experimental upstream, feature-gating and a documented migration path to the standard ListenerSet (expected around Gateway API 1.5) would be appropriate. Use cases Platform teams running SMP who want application teams to self-serve their own hostnames, listeners, and TLS certificates on a shared Gateway without granting write access to the central Gateway resource. Multi-tenant clusters that need to distribute listener configuration across namespaces. Environments migrating from NGINX Ingress that need a Gateway-native equivalent of per-team ingress ownership. Deployments approaching or exceeding the 64-listener limit on a single Gateway. Business value Preserves the developer self-service and separation-of-concerns model that NGINX Ingress users depend on, so the forced migration to Envoy Gateway does not become a regression in team autonomy. Keeps infrastructure lean by supporting a shared Gateway rather than one Gateway (and its associated pods) per team, and reduces the risk that customers stall on the 0.46.0 upgrade because the ingress replacement cannot match their existing operational model.

I'd like to see a centralized Harness.io team managed Slack App such that we can configure it once for our account, and then teams simply have to add it to their channel and pick the channel for the pipeline for notifications. Adding a Webhook for each channel for our Enterprise is challenging as we have IT approvals and/or adding new admins to our own "Slack App" so they have to create a new hook per channel.

We are updating our Sonarqube Server installation to 2025.5.0 shortly and have been given a recommendation that clients interacting with that should use sonar-scanner version 7.1.0 to prevent incompatibility issues. We would like the builtin Sonarqube scan step/plugin to be updated to allow us to specify the updated sonar-scanner version, or use the newer version by default.

provide support to restore cache dependency automatically using npm install for node without using custom path Currently It is supporting for yarn install with default path (.yarn) So If you can also provide support for npm install with default path(node_modules) then It will be really helpful for us.

Currently, there is no way to view all feature flags, their status, activity, etc across projects. The rollout board and environments tab can show feature flags for that project, but leadership would like visibility across all apps for a more birds-eye view of feature flag utilization. This would be useful to integrate into the Harness reporting capabilities.