Feature Requests

Create a centralized UI dashboard within Harness to view and manage enabled Feature Flags across the platform. Currently, users must call APIs to discover which feature flags are active. A UI would provide visibility, searchability, and ease of management for feature flag configurations, improving operational efficiency and troubleshooting capabilities.

Helm Services currently support multiple manifests but, K8s services do not. We'd like the ability to add multiple manifests to our Services so we can select them at run time or use an expression to dynamically switch them.

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.

We have an audit need to attach items to our servicenow ticketing system. This is supported by the API but not harness native steps. while a scripted workaround is possible, it creates a burden on our developers.

Could you please assist us in implementing API endpoint to fetch the Harness projects that a user has access to based on their email address? We are developing an external application that includes a dropdown to display the list of Harness projects. Instead of populating all available Harness projects, we need to filter and display only those projects that the logged‑in user has access to

Request native Orka integration for macOS VM build infrastructure in Harness CI. Customers using Orka cannot leverage Harness CI for macOS builds today (as opposed to customers using Anka). Please add first-class Orka support, including: Orka-based macOS VM provisioning Integration with CI pipelines (similar to Anka) Basic setup documentation

Current Behavior: The notification channel URL field currently only accepts secrets as input expression However, in our organization, the use of secrets is restricted, leaving us with no dynamic option to configure notification channel URLs. Desired Behavior: We would like the notification channel URL field to also support Harness variables as a valid input expression , providing a viable alternative to secrets.

I need asset id tag that is already added for a project to be displayed in the STO reports that we are exporting/downloading

Currently, when "After Terraform Plan" policies are enforced in IaCM, the evaluation occurs in the background. While the results are visible under the "Policy Evaluations" tab, they do not appear as a distinct step in the pipeline execution flow. Problem: From a developer experience (DX) perspective, the pipeline execution can fail without an obvious step boundary. This lack of visibility makes it difficult for application teams to understand: That a policy check is actually occurring. Why the transition from "Plan" to "Apply" failed without digging into a separate tab. Suggested Enhancement: Introduce a visible "Policy Check" or "Governance" step in the execution UI between the Plan and Apply/Approval stages. This step should: Represent the OPA evaluation phase. Provide direct links to the violation details upon failure. Ensure the execution flow matches the logical intent: Plan → Policy Check → Apply. Impact: Improves transparency and self-service for app teams as we scale IaCM across large organizations where governance is enforced centrally. Customer Context: Account: World Fuel Services Reference: Zendesk Ticket 112569

This is in relation to a previous ticket I have had open working with the Harness Reps. Specifically ticket #110470. Based off my discussion with Harness, Grace policies are only able to be created through a very manual process that is only possible by manually selecting findings/flaws after a scan has been completed. After that is completed, then you have to modify the existing OPA policy associated with that project. My suggestion here for a request is to update that process. Following Veracode specifically, as I have discussed with Abhishek Sahu, Veracode allows you to create a policy that can be associated to all projects and findings based on the discovered date. If a flaw is found on X day, then 30 days after the discovered date is when the pipeline will fail if left unfixed. Instead of it being a manual process, it should be added as a feature that will automatically be captured by Harness and its findings database. TL:DR Grace periods that are automatically catalogued instead of manually.