Feature Requests

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.

When using the DBApply step, if there is an error users are required to set up a second run step to parse execution logs for error messages to update ticketing systems, having the errors as an accesible expression during rollback would be really useful.

At this time, the build image that Harness uses is predefined and the only way to modify them is via API endpoints ( https://developer.harness.io/docs/database-devops/overview/#configure-harness-db-devops-image-versions ) For customers that have stricter security requirements, the default image may not always fulfill their needs such that it would be great if they could declare a specific image version when executing DB DevOps workflows in their pipelines.

Description Currently, Cloud Custodian does not support AWS DMS replication instances (aws.dms-instance) as a resource type. Due to this limitation, we are unable to implement governance and cost optimization policies for DMS replication instances. Use Case Customer requirement to identify idle DMS replication instances: Instances with no associated replication tasks Instances that are unused/idle for >30 days Include these in recommendations for cleanup or cost optimization At present, this use case cannot be achieved since the resource type is not supported in Custodian. Expected Outcome Add support for aws.dms-instance in Cloud Custodian Enable filtering based on: Instance attributes (ARN, status, creation time, etc.) Association with replication tasks Support standard actions like: Notify Tag Delete

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 need to automate the creation of generic webhooks via the harness provider for terraform Requirements: Generic webhooks can be created through the harness provider for terraform HMAC key authentication can be configured on generic webhooks through the provider EventRelay triggers created in a terraform run can reference generic webhooks created earlier in that same terraform run

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.

Description: Please consider enhancing the recommendation output for unattached EBS volumes so results can be grouped at the cloud account level rather than only at the individual resource level. At present, recommendations for unattached EBS volumes are evaluated and surfaced per resource. In larger environments, it would be helpful to support an aggregated view where a single recommendation can represent an account and include the list of matching volumes associated with it. Requested enhancement: Add support for recommendation grouping/output that can: • aggregate matching unattached EBS volumes by account • display one recommendation per account • include the list of matched resources within that recommendation Why this would help: This would make recommendations easier to review and manage at scale, especially in environments with many matching resources. It would also provide a more consistent summary view for governance and cleanup workflows. Current rule example: policies: - name: delete-unattached-aws-ebs resource: ebs filters: - Attachments: [] - State: available actions: - delete Current limitation: While the rule can identify the matching resources, the recommendation output does not currently provide an aggregated account-level representation with a list of all matched resources.

User wants a simpler way to handle short-lived secrets in Harness without storing them in Secret Manager. Use case is that an SRE starts a deployment pipeline and enters two temporary sensitive values: an API Key ID and an API Key PEM. These values need to be passed securely to later steps or stages for authenticated API calls. The main issue is that using Secret Manager for short-lived credentials creates extra work, since the secrets must be manually created, rotated, and deleted even though they are only needed for a short time.

Summary: We’ve observed significant performance degradation in Harness.io dashboards when applying filters, particularly due to the large volume of data being queried. To address this, we propose an enhancement that introduces a feature flag to scope filter options based on user visibility—determined by their roles and assigned resource groups. Details & Justification: Improved User Experience Filtering large datasets currently results in slow dashboard performance, which negatively impacts usability and responsiveness. By limiting filter options to only relevant data, users can interact with dashboards more efficiently. Security and Compliance Alignment Presenting all filter options regardless of access may inadvertently expose metadata about resources users shouldn’t be aware of. Restricting filter visibility supports a least privilege model and aligns with internal security and compliance standards. Scalability and Future-Proofing As data volumes continue to grow, the current filter mechanism will become increasingly inefficient. Implementing scoped filters now will help ensure the dashboard experience remains performant and scalable. Suggested Implementation Approach A configurable feature flag could be introduced to enable scoped filters based on user roles and resource groups. This would allow organizations to opt-in without disrupting existing dashboard configurations.