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.

Currently there is only once setting to enforce gitex in account, after that all the resources in the account are enforced to use gitex. We want a feature such that we can control which account resources we want to enforce gitEx. Please add that feature.

Provide ability to validate the inputs to a workflow form beyond the standard single value or regex validations. Something along the lines of the ability to call an external function or API to carry out a check and return a value to confirm allowed value, or writing an inline function to execute and carry out a validation. An example scenario could be checking for existing code repo name when providing a name for a new code repo to be created rather than having this fail at some point later during the pipeline execution.

When changing the weighting of items in the scorecard, it can be hard to understand what the real impact will be on the scorecard value. It would be very useful to have the weighting applied as a % in the form to better realize the impact of that scored item on the overall score.

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.

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.

Multi-Select option should be enabled. As per the documentation below it is mentioned to raise a service request with the Harness Support team for enabling the option. https://developer.harness.io/docs/platform/variables-and-expressions/runtime-input-usage#allow-multi-selection-and-single-selection

Under "limitations", Harness only allows the update of certain field types: https://developer.harness.io/docs/continuous-delivery/x-platform-cd-features/cd-steps/ticketing-systems/update-jira-issues-in-cd-stages/#limitations What we require is the ability to change a field for a group-type field, which is in a picker/single select format. We would like to ask for Harness to expand their list of supported field types to include this and other more commonly utilized fields.

Our customer has requested the ability to view service-level tags directly on the pipeline execution details page in Harness. These tags are important for them to track service ownership, environment classification, and internal metadata during and after deployments. Currently, as a workaround, we suggested using pipeline-level tags, which do appear on the execution view. However, the customer is not satisfied with this approach, as pipeline tags do not offer the granularity and relevance that service tags provide, especially in environments where a single pipeline may deploy multiple services.

Comments and split status are missing from the integration. Ven would expect this to be visible in the notification messages sent to Slack. Otherwise the base use case does seem to work, almost apples to apples comparison with the existing LaunchDarkly Slack app. Also, the team is concerned about if the Slack integration will be worked on further or not. This integration is important to them as they use Slack heavily for comms.