Feature Requests

FIS global has requested to support user group in E-Mail Step. This will help them to provide the user group for sending E-mails instead of manually adding all the users.

We have a use case where we want to use pipeline identifiers as project- or org-level tags. For example, we’d like to create a single tag like this: TagName:PipelineIdentifier1,PipelineIdentifier2,PipelineIdentifier3 However, when we enter comma-separated values, the system creates a new tag for each value after the comma, instead of treating the entire string as one tag. Our requirement is to create a single tag—TagName:Pipeline1,Pipeline2—rather than multiple separate tags.

To reduce load on developer teams, our product team would like to maintain Kubernetes workloads through our Centralized ECS Delegate. Currently, users that deploy into EKS have to create and maintain their own EKS delegates. This has been a pain point for our users and adds complexity to onboarding as well as overhead on the development teams.

Currently only for pipeline entities, gitconfig is available for policy evaluation. The feature request is to make this available for all entities backed by git manifest. This will allow use cases such as "disabling direct commits to main branch" or allowing pushes only on feature or release branches.

Description: Currently, when saving a stage as a template from a Git-based pipeline in Harness, the platform enforces the use of the same Git connector and repository as the source pipeline. While this default behavior is helpful as a suggestion, it should not be mandatory. Requested Enhancement: Provide users the flexibility to choose a different Git connector and repository when saving a stage as a template. This will allow users to manage templates independently of the pipeline source, which aligns better with modular and reusable design practices.

Today, the Splunk connector requires a delegate as part of the configuration. The Splunk connector is used for CV as well as audit trail streaming - the latter use case should allow for the connector to be configured to route through the harness platform directly as well, as Splunk has a SaaS offering, to reduce configuration overhead where approved within customer environments.

Is it possible to get a generic search bar that would just match keys and look for all resources, at the org level? One of the concerns teams have is they need to first find (search) the project inside an org and then search for a pipeline. Can we not have the org-level search look for pipelines too? Features: 1) Global Search Scope: Users can initiate a search query from any page within the Harness platform. The search scope covers all relevant artifacts, resources, and entities across Harness, including Projects, Services, Pipelines, Users and any other resource across the Account 2) Search Filters and Scopes: Users can refine their search results using predefined filters and scopes Filters may include options such as Project name, Service name, Pipeline name, etc. Scopes allow users to specify the context of their search within a particular Module/Org/Project. 3) Advanced Search Syntax: Support for advanced search syntax to enable users to construct complex queries. Syntax may include boolean operators, wildcards, phrase searching, field-specific searches, etc. 4) Autocomplete and Suggestions: Real-time autocomplete suggestions to assist users in formulating their search queries. Suggestions based on the user's input history, popular search terms, and relevance to the current context.

The Jira integration is currently too limited, and they'd like to be able to configure it for more than one environment at once. They use Jira for everything, so being able to track all environments in Jira would be useful.

Please provide an option to configure the Baseline so that it is set only on the first successful scan of the master/main branch. Currently, the Baseline is updated after every successful scan on master/main, which causes net new vulnerabilities to disappear from subsequent scans since the Baseline keeps shifting. As a result, builds are not being gated by new vulnerabilities, because each new successful scan resets the Baseline and removes the visibility of net new issues in following builds. This dynamic updating prevents us from blocking builds based on newly introduced vulnerabilities, which is a key requirement for our process.

Currently, when running terraform plan in Harness, the -lock=true flag is enforced in the command, and attempts to override it via TF_CLI_ARGS_plan environment variable do not take effect. We attempted to override the -lock flag by setting TF_CLI_ARGS_plan=-lock=false both as an environment variable and as a stage variable. However, the argument shown in the command in step logs remains -lock=true, and the state still gets locked during the plan step. This will allow teams to control locking behavior during plan (e.g., disable locking for read-only plan runs while keeping it enabled for apply runs). Without this capability, plan steps in Harness unnecessarily lock the state, potentially blocking other operations.