Feature Requests

Environments on the flag view are in no particular order making them hard to manage. On most other pages, environments are listed alphabetically which seems reasonable to me but they don't flow like we think about feature management. Most of the time, we're enabling in a lower env then elevating incrementally through environments. I want the ability to choose the display order. In a perfect world too, I want to initialized environments shown on top in my specified order while uninitialized environments are shown below in order to keep flags clean and easy to manage.

In reference to this feature request: https://ideas.harness.io/feature-request/p/output-terraform-plan-init . I would like to see an option for the full terraform plan output and have it posted to a comment on a pull request. Currently we see something like this: ✅ Terraform plan complete! 🏢 Org: <...> 📖 Project: <...> Workspace: <...> Planned Changes 3 Added ~ 0 Changed ~ 0 Deleted ~ 826 Unchanged ~ 0 Imported ~ 0 Removed The table of planned changes can be viewed in Harness. Outputs No outputs present View details in Harness <--- This is a link to terraform I would like the option to enable full output, or at least some portion of the output if it is a very large plan. For small plans, it would take one less step to review the PR.

Supply chain attacks compromise a dependency, action, or base image that a pipeline pulls in, and the malicious code then runs inside the build with access to credentials, network egress, and the filesystem. Recent incidents like the litellm compromise are examples of this. Existing controls are static, dependency and image scanning catch known-bad artifacts before execution, but not a package that scans clean and behaves maliciously at runtime. Today there is no way to tell whether a build contacted an unexpected host or read files outside its scope.

Currently, the "CC User Groups" picker in the Email step does not display or allow selection of inherited user groups that originate from the Account scope and are inherited into Organization or Project scopes. Only user groups that are created natively within the current Organization or Project scope are available for selection. This behavior is inconsistent with other parts of the Harness platform, where inherited user groups are visible and can be managed successfully. As confirmed during discussions with Harness Support and Engineering team, inherited user groups currently do not appear in the Email step picker and supporting them would require a product enhancement. This limitation creates operational and security challenges for organizations that centrally manage user membership through Account-level Active Directory synchronized user groups. Since inherited copies cannot be selected in the Email step, customers are forced to reference the original Account-level user groups directly. In webhook-triggered pipelines that execute under Service Accounts, this may require additional account-level permissions solely for user-group resolution.

Enterprise customers need more granular control over permissions within Harness. Today, some RBAC permissions can provide access to multiple actions, making it difficult to enforce a true least-privilege model for specific operations. Requested Enhancement: Allow administrators to independently control permissions for individual actions within Harness, rather than having multiple actions governed by the same broader permission. This would provide greater flexibility for organizations that need to restrict specific operations while allowing users to retain access to other related functionality. Customer Impact: More granular, action-level permissions would help enterprise customers implement least-privilege access models and better align Harness RBAC with their internal access-control requirements.

Hi Team, Today, when a main pipeline invokes a chained (child) pipeline using the Pipeline step, the entire child pipeline executes — there is no native mechanism to select or filter specific stages from the child pipeline at the time of invocation from the parent. When combined with looping strategies (Matrix / Repeat), this limitation means every loop iteration executes all stages in the child pipeline, even when only a subset of stages is relevant for a given iteration. Scenario: A main pipeline deploys to multiple environments using a Matrix loop. Each environment requires only a specific subset of stages in the child pipeline (e.g., dev needs Build + Deploy, prod needs Build + Deploy + SmokeTest + ApprovalGate). Today: Two separate child pipelines must be maintained, or complex when conditions must be embedded in the child pipeline for every possible combination. With this feature: A single child pipeline is maintained, and the main pipeline selects the relevant stages per matrix iteration:

Looking to manage Harness GitOps Agents through Terraform while using existing, customer-managed ArgoCD installation. Today, the harness_platform_gitops_agent Terraform resource does not appear to support this BYOA model. The Harness API supports metadata such as existingInstallation and infraType, but these fields are not currently available in the Terraform provider schema. As a result, customers using an existing ArgoCD environment cannot fully manage their GitOps Agent configuration through Terraform and must create the GitOps Agent manually in the Harness UI. Requested enhancement: Add Terraform support for configuring a GitOps Agent against an existing ArgoCD installation, including the ability to specify the relevant BYOA metadata, such as: existingInstallation infraType Other configuration required to associate the Harness GitOps Agent with an existing customer-managed ArgoCD instance

Hello Harness Support, We would like to request that the feature flag PL_ENABLE_OPA_FOR_VARIABLES be enabled for our Harness account. Our organization is implementing governance controls and standardized naming conventions across Harness entities, and we need the ability to enforce custom naming standards for Variables at the Account, Organization, and Project levels using OPA policies. Based on Harness documentation, enabling this feature would allow us to create policy sets for the Variable entity type and enforce naming conventions during the On Save event. The built-in variable naming restrictions do not provide the level of customization required to meet our organization's governance requirements. Please confirm whether this feature is available for our account, enable it if possible, and provide any prerequisites, limitations, or additional guidance for implementation

https://support.harness.io/hc/en-us/requests/121755

Hello Harness Support, We are trying to configure an Jfrog Artifactory connector using OIDC authentication in Harness. We are receiving the following message: This feature is behind the feature flag CDS_ARTIFACTORY_OIDC_AUTHENTICATION. Contact Harness Support to enable the feature. Could you please enable the following feature flag for our Harness account? Feature Flag: CDS_ARTIFACTORY_OIDC_AUTHENTICATION Harness Account ID: YzRhNTgyNzEtNjIyZi00ND This is required for us to configure OIDC authentication with our JFrog Artifactory connector. Please let us know if you need any additional information. Thanks, Naveen