Feature Requests

today, it does not appear to let you do BOTH inputSetName + inputset in IDP workflow action. inputsets let you group entities that are defaulted for say an environment (e.g. envIdentifier, infraIdentifier), but a user will want to be able to override some inputs and pass in a parameter for a artifact version or location.

We are requesting native support for Snyk Reachability Analysis metadata (or generic custom SARIF properties/tags) in the Harness STO UI. Currently, when ingesting Snyk results using the native type: Snyk step, Harness STO's normalization engine strips out custom SARIF properties and tags. As a result, our developers lose all visibility into the reachability status of their vulnerabilities in the STO dashboard. Please add the ability to display Snyk Reachability states (e.g., "REACHABLE", "NO PATH FOUND") natively in the STO UI. This feature is critical for our teams to filter out non-exploitable vulnerabilities and reduce security triage noise.

Please expose organization-level tags in pipeline policy inputs through a field such as metadata.orgMetadata.tags, similar to the existing metadata.projectMetadata.tags. This would allow account-level policies to evaluate organization tags and apply governance controls based on attributes such as environment, risk level, ownership, or purpose. Currently, policies must hardcode organization identifiers. This is difficult to maintain, does not scale as organizations are added or renamed, and tightly couples policy logic to the organizational structure. Using tags instead would allow policies to: Target groups of organizations dynamically. Be reused across different organizational structures. Change scope by updating tags rather than policy expressions. Remain scalable and resilient as the account evolves. Please add organization metadata, including organization tags, to the available pipeline policy inputs.

Two automated state transitions are blocked due to missing event triggers in Harness. Required transitions: (a) "In Progress → In Code Review" — trigger: non-draft PR with ≥1 reviewer assigned; (b) "In Code Review → Ready for QA" — trigger: PR not in draft + required approvals obtained + comments resolved + quality gates passed + security gates passed

Build a feature to support Multiple Github Repository or Sub Github Repository using TechDocs. If this feature is not available then developer have to move all their documents to one master repository.

I want to be able to do Bayesian analysis in FME's warehouse native experimentation so our Product team does not need to rely on the Data team to do the Bayesian analysis for them. Most of our experiments are done with small sample sizes where frequentist methods are not practical, and hence Bayesian analysis is required.

Allow configuring the per-IP rate limiter for the FME API to accommodate use cases that require a higher-than-default limit but cannot spread requests across multiple IPs.

Currently, the GitOps application Helm values configuration does not support supplying values as native structured types, such as objects, arrays, booleans, etc. This limitation requires us to either encode complex Helm values as strings or rely on indirect values files.

Currently, the Webhook notification channel type in Harness does not support configuring a custom request body. The webhook sends a notification without a payload body, which makes it impossible to integrate with external systems that require a body in the HTTP request. Use case: We use webhooks to trigger automated AWS agent investigations whenever a pipeline step fails (e.g. GitOps sync failures, timeout errors). The AWS endpoint receiving the webhook requires a JSON body to identify the pipeline, stage, execution context, and failure reason. Without body support, the webhook call is rejected and the automation cannot be triggered. Requested behavior: Allow users to define a custom body for webhook notifications, with support for Harness expression variables (e.g. <+pipeline.executionId>, <+ pipeline.name >, <+ stage.name >, <+failure.message>) so the payload can carry execution context dynamically.

Currently in stage names, and pretty much any other string value. When the string is too long to fit in the column, Harness truncates it and adds a trailing "..." We would like the option to have the text wrap. In particular this would be useful in stage names, but ideally, any time we are getting the "..." truncation, we could instead get a text wrap.