Feature Requests

Currently, when a pipeline fails in Harness, the default notification payloads (e.g., email, Slack) include a helpful errorMessage field that captures the cause of the failure, such as: "errorMessage": "Shell Script execution failed. Please check execution logs." However, when using custom notifications via JSON notification templates, this field is not available as a variable, preventing customers from including critical error context in their custom messages. Feature Request: Expose the errorMessage field in custom notification templates for the following failure types: Step failure (eventType: StepFailed) Stage failure (eventType: StageFailed) Pipeline failure (eventType: PipelineFailed) Use Case: This enhancement would allow customers to build richer and more actionable custom alerts — especially for use cases where notification delivery is routed to internal tools, messaging platforms, or monitoring systems that rely on structured JSON. Example: In the default notification payload for a failed step, the following structure is provided: { "eventData": { "pipelineName": "Simple Pipeline with Runtime Inputs", "stepName": "ShellScript_1", "eventType": "StepFailed", "nodeStatus": "failed", "errorMessage": "Shell Script execution failed. Please check execution logs.", ... } } We would like to have the errorMessage field accessible in the custom notification template so we can include it in our Slack/webhook payloads.

Currently, when rerunning a pipeline execution, the system utilizes the latest pipeline definition but retains the original inputs. However, this behavior makes it difficult to reproduce past pipeline executions, which is a recurring frustration for engineering teams. We are requesting the ability to rerun a pipeline with both the original pipeline definition and the original inputs, ensuring true reproducibility of past executions. The feature could be implemented as a configuration option that allows users to choose whether to rerun with the latest or the original pipeline definition. For our account, we would prefer this configuration to default to the original pipeline definition. This enhancement would greatly improve debugging and provide more reliable historical execution reproducibility. We are hoping to have this feature included in the roadmap for Q4.

Currently we do not consider the delegateSelectors while sending the notifications via delegate. This is a request for the Notification Service to honour the DelegateSelector config, if the notification is configured to be sent through Delegate.

Often times I'm working in a specific area/module within the product and I need to repeatedly search for different things in the docs. For each search, I need to go and specify the module filters to narrow down the results to only the area/modules I'm working on. It would be a much better experience to have the module filter persist so that I can search repeatedly and relevant/filtered results without having to manually re-filter every single time.

We would like the ability to create Dashboard Folders to be supported by the terraform harness provider.

Hello, We need to be able to override delegate image per individual delegates that we install in particular projects. Currently we can deploy individual delegates of choice when the source image is from docker hub. But when it comes to custom images with auto upgrade ON, we lose the ability to install delegate image of choice per delegate in the account. The API "override-delegate-tag"( https://apidocs.harness.io/tag/Delegate-Setup-Resource/?_gl=1 2yt76s _gcl_au MzIxNjg5MjM0LjE3MzcwMTg3ODY. _ga NDgyMzAxNDIxLjE3MTY0NTU5Mjc. _ga_46758J5H8P*MTczODAzODU2NS43NS4xLjE3MzgwMzg1OTUuMzAuMC4w#operation/overrideDelegateImageTag) sets the delegate override tag at account level. We need to be able override delegate Tags at the delegate level. This is so that we can have multiple delegates custom/docker working simultaneously and yet still retain the ability to auto upgrade.

In vault, as of now for vault secret, AppRole option only works using the default auth path “approle” while creating a Harness Vault connector and does not work for non default paths so need support for non default paths too.

User wanted to make notification method configurable so this will significantly improve usability. because at this moment, when configuring pipeline notifications, the notification method is not configurable, which is very rigid and forces all development team to stick to the same notification mechanism.

We need to provide the ability to import secrets from the external secret managers and create them as reference secrets in Harness ... Also, the ability to Periodically check for new secrets and create them in Harness On-demand import of new secrets

=> Lets create a template of type "Secrets Manager" having some "Template Inputs" => And this templates to create 'Custom Secrets Manager' connector , then the input variable value can be 'Fixed Value' or 'Expression' (of type "secret" only). => Here we have a requirement, where we want to use 'Expression' as a variable (it could be pipeline variable, stage variable or project level variable) => These variable values can be changed between 2 executions of same pipeline, without having to go back and change inputs in 'Custom Secrets Manager' connector.