Feature Requests

We would like to request an enhancement to the default webhook payload for the "Waiting for User Action" event in Harness. Currently, when a pipeline triggers a "Waiting for User Action" event (e.g., when an approval step is pending), the default webhook payload does not include the name or identifier of the specific step that is awaiting user input. Requested Enhancement: Please include the step name and/or step ID as part of the default webhook payload when a "Waiting for User Action" event is fired. This would allow downstream systems and integrations to easily identify which specific approval step requires attention. Use Case: When pipelines contain multiple approval steps, receiving the step name/ID in the webhook payload would enable teams to route notifications more effectively.

We would like to request the following enhancements to the custom notification templates in Harness: 1) Step-Level Variable Support in Custom Notification Templates: Please add the ability to reference and utilize step-level variables within custom notification templates. Currently, notification templates lack support for step-level variables, limiting the granularity of information that can be included in notifications. 2) Expression for Retrieving Approval Step Messages: Please provide a dedicated expression that allows users to retrieve the message associated with an approval step.

Currently the Last Sync Details only shows the status of individual resources and if they were synced or not. We would like to see the options that were applied for the Sync. This is done in the ArgoCD UI as the information is in the Argo App.

Some pipeline failures occur during validation or rendering for example, invalid YAML or unresolved expressions before execution starts. These failures do not generate console logs, so they cannot be captured or sent to external systems like Splunk. We need a way to expose these errors in logs or via API so they can be monitored and ingested like runtime failures.

Currently, Continuous Verification (CV) in Harness with Dynatrace integration supports only APM services (application-level metrics such as response time, error rate, etc.). However, there is a need to extend this functionality to include infrastructure-level metrics, specifically for Kubernetes workloads (such as deployments, pods, containers) and delegate deployments. Use Case: In Kubernetes environments, monitoring infrastructure components such as: Delegate deployments Pod resource metrics (CPU, memory, etc.) Container health and restarts is essential for ensuring the overall health of the system. These components are critical to the application’s performance and should be included in the Continuous Verification process to allow automated validation and rollback based on their health. Proposed Enhancement: We propose the addition of support in CV with Dynatrace for: Selecting Kubernetes workloads (pods, containers, deployments) as monitored services within Dynatrace for CV Verifying infrastructure-level metrics (such as CPU, memory usage, pod health, and restarts) as part of the CV process Allowing CV to trigger automated actions (e.g., rollback, notifications) based on infrastructure health, similar to how it currently works with APM services Benefit: This enhancement will enable teams to use Continuous Verification in Dynatrace for both application services and infrastructure workloads, improving the ability to detect performance issues early and apply automatic rollback strategies for both types of resources.

Currently, the GitOps sync step performs synchronization for the entire application. However, Argo CD allows selective synchronization of individual resources through its UI. We request support for similar functionality within the sync step, enabling users to selectively sync specific resources from an application instead of synchronizing all resources.

Enable post-deployment rollback for GitOps-managed services, allowing users to revert to a previous Git revision directly from Harness. Problem When using GitOps workflows, rollback requires manual Git operations or external tooling. This slows recovery and introduces risk during incidents. Requested Capability Trigger rollback to a previous commit, tag, or chart version from Harness Visibility into deployment history with one-click rollback Parity with non-GitOps deployment rollback experience Value Improves incident response time and operational consistency for teams standardizing on GitOps.

Currently, Harness only supports adding User Groups or Service Accounts in the Approval step. We'd like the ability to provide a list of user emails instead of defining a group for the approval.

In GitOps, we have a Resource View where users can see all of the resources they've deployed per their Helm Chart i.e. Deployments, pods, services, etc. We'd like to have a similar view for regular Kubernetes and Helm deployments as well. We like the ability to use the Deployment Strategies like Rolling, Blue/Green, and Canary but, we also want to give our users a holistic view of what resources they are deploying and if they are healthy or not.

Application teams would like to have a way to 'lock' a pipeline so that further builds cannot overwrite their changes while QA and dev teams validate. An option like Jenkins had to 'temporarily disable this pipeline' from running would be very handy.