Feature Requests

Our team would like to be able to look up and display or use preexisting Harness variables in an IDP workflow. An example would be to lookup up a variable in a project such as a variable storing the selected Java version.

When using the SelectFieldFromApi ui:field in the IDP, our team would like to have an option to auto select the first result in the list of results.

In order to make API calls with a user's permissions in the IDP using the ui:field: SelectFieldFromAPI, our team needs to obtain a user's Harness API Auth key from their short lived JWT token.

Our team needs to be able to dynamically resolve variables in the headers section of the ui:field SelectFieldFromApi. The resolved variables need to be previous inputs from the IDP workflow. Here is an example: ui:field: SelectFieldFromApi ui:options: title: Title description: Description request: method: POST headers: x-api-key: "token" body: This is a simple plain text message Currently it is possible to resolve variables in the body section, but not the headers. A separate ticket is being made to obtain a Harness API Auth key from a workflow JWT token.

We would like to propose an enhancement to improve the flexibility and accuracy of Scorecard evaluations. Currently, scorecard checks operate independently and contribute cumulatively to the overall score. However, in certain use cases, we need the ability to define mutually exclusive checks, where only one condition should apply at a time, and the outcome should depend on which condition is satisfied. Proposed Enhancement: Allow grouping of checks as mutually exclusive Assign weightage or priority to each check within the group Based on the check that passes, derive a final state: 🟥 Red 🟨 Yellow 🟩 Green Example Use Case: For evaluating .NET versions: If version < 4.8 → Red If version = 4.8 → Yellow If version ≥ 6.0 → Green Only one of these conditions should apply, and the score/result should reflect the most relevant matching condition, rather than aggregating multiple checks.

The GitHub integration for scorecards currently provides the ability to "extract a string from a file." It is very limited in that one has to essentially hard code a specific file. It makes writing a rule like "I want to score my code by the versions of .NET they are built against" or anything else that might match multiple files. In a larger enterprise, one will deal with a lot of variation in specific file names, so the ability to scan configuration files or any other meta data by a file extension or other pattern would be extremely useful. Without that, the only option would be to hard code hundreds of explicit file names, making IDP management very unwieldy.

I would like to be able to use metadata such as Workflow name, task ID of Workflow execution, and Workflow execution timestamp as variables, so they can be referenced downstream as Pipeline inputs.

Kubernetes API on catalog not pulling logs, when checked delegate logs, it is ignorning port Our config -> <<hostname>>:6443 port 2026-03-05 09:17:20.609 UTC [task-exec-50822] ERROR io.harness.network .Http - Could not connect [taskId=jsssGZO2Qm-NOMveZM7kYA-DEL, URL=https://<<hostname>>/api/v1/namespaces/customerfnbza-opm-stress/pods/opm-write-api-6c4cf56b48-99vp2/log?container=opm-write-api] java.util.concurrent.ExecutionException: java.net .ConnectException: Connection refused at com.google .common.util.concurrent.AbstractFuture.getDoneValue( AbstractFuture.java:596 ) at com.google .common.util.concurrent.AbstractFuture.get( AbstractFuture.java:555 ) at com.google .common.util.concurrent.AbstractFuture$TrustedFuture.get( AbstractFuture.java:111 ) at com.google .common.util.concurrent.Uninterruptibles.getUninterruptibly( Uninterruptibles.java:247 ) at com.google .common.cache.LocalCache$Segment.getAndRecordStats( LocalCache.java:2349 ) at com.google .common.cache.LocalCache$Segment.loadSync( LocalCache.java:2317 ) at com.google .common.cache.LocalCache$Segment.lockedGetOrLoad( LocalCache.java:2189 ) at com.google .common.cache.LocalCache$Segment.get( LocalCache.java:2079 ) at com.google .common.cache.LocalCache.get( LocalCache.java:4017 ) at com.google .common.cache.LocalCache.getOrLoad( LocalCache.java:4040 ) at com.google .common.cache.LocalCache$LocalLoadingCache.get( LocalCache.java:4989 ) at io.harness.network .Http.connectableHttpUrlWithHeaders( Http.java:363 ) at io.harness.delegate.task.executioncapability.HttpConnectionExecutionCapabilityCheck.performCapabilityCheckWithProto( HttpConnectionExecutionCapabilityCheck.java:78 ) at software.wings.delegatetasks.delegatecapability.CapabilityCheckController.lambda$validate$2( CapabilityCheckController.java:79 ) Details on request -> https://support.harness.io/hc/en-us/requests/105682

Description: Today Backend Proxies only support GitHub token (PAT) authentication. We’d like to use GitHub Apps instead (App ID / Installation ID / Private Key) since GitHub Apps are the more secure and recommended integration model. Why this matters / impact: • Many enterprises avoid PATs due to broad scopes and operational overhead (rotation/user-coupling). • GitHub Apps provide least-privilege, auditable, installation-based access. • Lack of GitHub App support blocks adoption of Backend Proxies for teams with strict security/governance requirements. Requested enhancement: Add a GitHub App authentication option to Backend Proxies, using the GitHub App installation token flow, including clear guidance on required permissions.

Summary When re-running/retrying an IDP workflow that uses conditional inputs (e.g., fields that depend on connectionType), values from the previous selection remain in the workflow form data. This causes the Review step to show fields from both the old and new selections, which is confusing and can lead to incorrect submissions. Problem / Current behavior • Workflows with conditional parameters (dependencies / oneOf / if-then) behave correctly while filling the form. • However, on Retry/Re-run, if the user changes the selector (e.g., azureblob → documentdb), the previous branch fields remain in the underlying formData. • The Scaffolder Review page reads from the full formData, so it displays “old + new” fields together. Expected behavior On Retry/Re-run, when the user changes a dependency-driving field (like connectionType), fields not in the active schema branch should be removed from the form data so only the current branch appears on Review and is submitted. Why this matters (Impact) • Confusing UX during Review • Higher risk of submitting stale/irrelevant parameters • Common use-case for connection/config workflows (Azure Blob vs Cosmos DB vs SQL, etc.) Requested enhancement Enable (or provide a supported configuration option to enable) RJSF behavior that removes inactive fields from formData, such as: • omitExtraData • liveOmit so that hidden/inactive fields do not persist across Retry/Re-run and do not appear on Review.