Feature Requests

Before enabling an OPA Policy, we want to know how many pipelines will be impacted by the OPA Policy. Understand the radius of the OPA Policy - how many projects and pipelines it is impacting Identify errors that will occur when enabling an OPA Policy to fix prior to enabling it

Problem Statement: Currently, OPA policies cannot resolve expressions and variables during runtime evaluation. When a pipeline variable references a project-level variable (e.g., <+variable.cpu_limit>), the OPA policy receives the expression string itself rather than the resolved value. This prevents runtime governance of resource limits based on dynamically configured values. Use Case: We need to enforce CPU resource limits across all pipelines using OPA policies that evaluate at pipeline runtime. Teams should be able to configure their resource limits via project variables, but these limits must be capped by OPA policies (e.g., max 6 CPUs) during pipeline execution. Current Limitation: OPA policies work correctly on "save" when values are static At runtime, expressions are not resolved, causing policies to fail validation The PIPE_IS_PRE_STEP_OPA_POLICY_EVALUATION_ENABLED feature flag only works at step-level, requiring individual configuration per step. Also, there is no information at the step level inputs on Resource limits, so this is anyway not possible. This doesn't scale for global enforcement across custom pipelines Requested Enhancement: Enable OPA policies to resolve all expressions and variables (including project/org/account variables) during runtime evaluation at the pipeline level. This would allow: Global resource governance across all pipelines Dynamic configuration through variables while maintaining policy controls Runtime enforcement without requiring step-by-step policy configuration Support Ticket: https://support.harness.io/hc/en-us/requests/101501

Make budget alert notifications context-aware by evaluating spend against the position within the budget period, so users are only alerted when the spending pace represents a real risk of overrun. Problem CCM Perspectives budgets currently support six threshold alerts (Actual 50/80/100% and Forecast 50/80/100%). Alerts fire purely on the percentage threshold, with no awareness of where we are in the budget period. Example: a "Forecast 50%" alert triggers the same way on day 5 of the month as on day 25 — even though these have very different financial meanings. This produces noise on normal spend patterns and dilutes the signal when a real risk exists. Requested behavior Introduce dynamic, time-aware budget notifications that evaluate both: Budget consumption percentage Progress through the budget period The platform should decide whether the current spending velocity indicates an elevated probability of exceeding the budget, and alert accordingly. Example (monthly budget, Forecast 50%) Day 8 → Notify. Velocity suggests likely overrun before month-end. Day 15 → Optional notification, depending on configurable tolerance. Day 25 → Do not notify. Normal spending behavior; no user attention needed. Suggested configurability Toggle between "Static thresholds" (today's behavior) and "Dynamic / time-aware" mode per budget. Configurable tolerance band for the "warning" zone. Applies to both Actual and Forecast alerts, across monthly / quarterly / yearly budget periods. Benefit Reduces alert fatigue, surfaces only financially meaningful risks, and improves budget governance across Perspectives.

The cost forecasting in CCM Budgets currently looks like all it does is add 5-15% for each future month and that's it. There's no variation we're seeing to bring it more in line with historical costs or any alignment, the cost just goes up and that's it so not much is being done there currently. The second (but primary) thing we need is to be able to configure our own values for future forecasting months in budgets.

Request a Harness-supported API endpoint that allows authorized automation to update an SCS license family and manage direct and indirect dependency relationships in a way that is compliant with internal firm standards (e.g., governance, auditability, RBAC, validation, and change controls). Without an API: -Changes are manual, inconsistent, and hard to govern -We cannot enforce required approval, validation, or audit controls -Dependency graph correctness drifts, increasing operational and compliance risk

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.

I would like to request an increase in the character limit for the tests tab, as the current 8,000-character limit is insufficient for storing detailed test results. Expanding this limit would greatly improve usability by allowing more comprehensive data to be saved and reviewed within the platform.

Recommendations workflow is clunky where I: Filter a list of recommendations that is unique to my group/platform-> Click into a recommendation-> recommendation appears within the page instead of a new tab -> I gather the recommendation then I must go back to the results filtering page to click on another recommendation. Can I suggest to open a new tab everytime I click into a recommendation. So I can preserve the filtered list whilst still being able to collate all the recommendations I need

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.