Feature Requests

Description The customer has requested support for pipeline-level execution concurrency limits with execution queueing to better control high volumes of pipeline executions. Use Case The customer's CD pipelines are triggered by AWS Auto Scaling Groups, which can generate a large number of pipeline executions simultaneously. This results in significant delegate resource consumption and increased infrastructure costs. The customer is looking for a mechanism to throttle execution at the pipeline level while ensuring all executions are eventually processed. Requested Functionality Configure a maximum concurrency limit for an individual pipeline. Queue any executions that exceed the configured concurrency limit instead of rejecting or running them immediately. Automatically start queued executions as active execution slots become available. Enhancement Request The customer also requested consideration for a dynamic concurrency model that adjusts the allowed concurrency based on available delegate capacity. Example: 1 delegate → 20 concurrent executions 2 delegates → 40 concurrent executions 3 delegates → 60 concurrent executions This would allow execution throughput to scale automatically with available delegate capacity while preventing sudden execution spikes from overwhelming delegate infrastructure. Customer Benefits Prevent delegate resource exhaustion during traffic spikes. Reduce delegate infrastructure costs. Improve deployment stability during burst workloads. Enable automatic scaling of deployment throughput based on delegate availability.

We are looking for a centralized mechanism within Harness where policy exceptions can be recorded, reviewed/approved with validity periods, and then automatically considered during OPA policy evaluation so that approved exceptions do not result in policy enforcement failures. With this managing and tracking OPA policy exception within the Harness UI would really help to provide better control.

Currently, Overlay Input Sets merge multiple input sets into a single pipeline execution. We would like the option to trigger separate pipeline executions when multiple input sets are selected, allowing the same pipeline to run independently and simultaneously for each input set. This would reduce manual effort, simplify multi-environment deployments, and provide better support for parallel execution use cases while maintaining individual execution tracking and visibility.

We have scenario about repositories type - infra that this repos not exist backend file tf cause this file's buiding in runtime pipeline in github action, we've including this file in runtime before to start terraform plan and apply.

Currently most everything a pipeline reference can be stored in a git except 2 things. Variables and Overrides V2. I see there is already an RFE for overrides v2 to be backended by git. RFE to allow variables to be stored in git. Now that services are allowed to be stored in git, the variables associated with service are in git. Would request to keep this user experience across the board where variables are first class git citizens

Please add wildcard search to search functionality for Executions list. We have team that would like that.

Harness RBAC should allow restricting access to the Events and Logs within the Resource View. The underlying ArgoCD allows this via their RBAC, but it'd be nice if we could restrict access via Harness roles so we could get finer grained control: Some operators only need access to see the health of a resource, not the logs.

I would like to request the ability to publish test reports from a Run step within a Custom Stage or Step Group. These types of stages are used to execute QE automation scripts and will provide a lot of benefits for viewing results and providing summary of state of automation test runs.

We're trying to use the AWS Pod Identity association feature in AWS EKS, but it doesn't seem to be working. Could you please enable support for this feature?

When a Harness pipeline is triggered by a Webhook (for instance Gitlab triggered the pipeline when code is committed), the pipeline executions page -> Execution Start time column currently shows the owner of the Harness API key that is used in the Webhook. It is not very useful. Instead can you display user's email who committed the code in Gitlab?.