Feature Requests

Request for bulk approval functionality to allow approvers to review and approve/reject multiple approvals simultaneously, improving efficiency for teams managing approvals during deployments.

Files attached to Manual Activities in Release Orchestration (such as audit evidence uploaded by approvers or task assignees) are stored in Harness-managed storage, and there is no way to point them at a bucket the customer owns. Please add a setting to configure a customer-owned storage like an AWS S3 bucket for example (with the connector, permissions, and encryption options needed) as the storage location for these attachments. Regulated customers need release evidence to live in storage they control so they can meet data residency, retention, and audit requirements, and so their security and compliance teams can state exactly where those files reside. Until then, documenting where attachments are stored, retention, and size limits would also help.

Summary SGWS wants to complete the approval for an IDP workflow-triggered pipeline from within the IDP workflow itself, without navigating to the pipeline. Current behavior A user runs an IDP workflow, which triggers a Harness pipeline. The approval step is defined at the pipeline level. The approver must leave the workflow and open the pipeline execution to approve. Requested behavior Either of the following, in order of preference: Approve directly in the IDP workflow view, next to the logs and run status. Approve by replying to an email notification. Business impact Users run everything from the workflow and don’t have access to the DevSecOps project scope where the pipelines live. Forcing approvers into the pipeline UI breaks the self-service flow.

When a step fails on Kubernetes build infrastructure, the build pod is cleaned up immediately. For steps that log very little, such as Harness-provided plugin steps, there is often no time to run kubectl logs, and node-level log forwarders (Splunk, Fluent Bit and similar) cannot ship the container output before the pod is deleted. This makes failures hard to debug and leaves gaps in a team's own observability pipeline. Please add an option, at the pipeline or infrastructure level, to retain the build pod for a configurable period after a failure before cleanup. Alternatively, guarantee that step stdout and stderr are flushed to the Harness log service before teardown. This would help CI and IaCM users who run builds on their own clusters and need to troubleshoot failures that currently leave no trace.

Google now recommends DNS-based access to the GKE control plane, and some teams are turning off IP-based access completely for security reasons Right now the Harness GCP connector doesn't handle clusters that only have the DNS endpoint. Deployments to them fail with a TLS validation error, because the connector seems to check against the cluster's own CA certificate while the DNS endpoint presents a Google-managed one. A narrow fix exists for clusters with IP access fully disabled, but it's a stopgap, not a supported option. It would be great to have proper DNS endpoint support in the GKE infrastructure options, ideally as an opt-in setting so nothing changes for people who rely on an IP endpoint today, for example for proxy configuration. This matters most for teams moving to Workload Identity Federation so they don't have stored keys or tokens. For them, going back to an IP endpoint or a manually managed service account credential defeats the point of the migration

I want to have FME AI configs integrate with popular AI chat/voice vendors like Eleven Labs.

When configuring a pipeline with a Git connector, the branch selection dropdown attempts to list all available branches in the repository. For repositories with a large number of branches, this can make it difficult for users to find and select the relevant branches. Introduce a regex-based filter option that allows users to define patterns to display only matching branches in the pipeline configuration. This would simplify branch selection, improve usability, and reduce clutter when working with pipelines containing a large number of branches.

Hi Team, Currently, OpenTofu/Terraform plan output in Harness IaCM pipelines is displayed as plain text. We would like support for color-coded plan output similar to Azure DevOps to improve readability and help users quickly identify infrastructure changes. Expected Behavior: + Create → Green ~ Modify → Yellow Delete → Red -/+ Replace → Orange/Purple Benefits: Faster plan reviews Improved readability Easier identification of destructive changes Better user experience for OpenTofu/Terraform users Thanks, Nagarjuna CDO Infrastructure Team The Huntington National Bank

Hi, we provision our gitops agent now via terraform and we could not find the options to enable the DR mode using the harness terraform provider. It seems the only way to do it at this moment is using click-ops, but we need to do it using IAC and automatic provisioning, not manual actions.

Custom secret manager templates stored at the account level do not resolve org.identifier and project.identifier to the project associated with the pipeline at runtime, unlike step or stage templates, which perform this resolution. Consequently, project-level restrictions and validations cannot be enforced when accessing secrets.