Feature Requests

On the Segment page in Harness FME, there's a dropdown for filtering the types of segments visible to "Standard". To see other types, you have to manually click the dropdown and select another type (such as "Rule-based"). It would be convenient to have an option (and to default to this option) where we see segments of "All" types. More than once now, we've had developers not be able to find any segments because they weren't the most common type of "Standard" and I agree it isn't obvious that the filter needs to be adjusted to see a non-empty page. It doesn't tell the user it's showing # out of # segments, it instead implies that no segments exist for this project.

Current state when an approver follows a link to approve a flag change, they get lots of info: the flag name, the the environment, and any additional fields the requestor chose to fill out. We have chosen to use tags to identify what flags may be consumed by which microservice(s). We'd like to add the tags on that flag to this form for standardized, guaranteed context for approvers. That way the approver gets a better idea of the impact they're approving without having to rely on the requestor explicitly going out of their way to add in that context to the optional fields. Hopefully it's a small change!

One of the most convenient features of Harness FME is the ability to take a flag definition and copy it from one environment to another. This helps take the toil out of reconfiguring identical definitions that may have complex targeting rules. Could we have the same feature for segments? It would be nice to look at a Segment definition and when navigating to a different environment, get prompted to either "Add a definition" or "Copy from" so that lengthy segments don't have to be redefined manually. Screenshots attached of the option we have for flags, but not for segments.

Following the customized notification template docs( https://developer.harness.io/docs/platform/templates/customized-notification-template/ ), we can customize Slack notifications effectively — except for the ability to @mention the individual responsible for a commit directly in Slack. We can retrieve the commit author's email using expressions like <+trigger.committerEmail> or <+pipeline.triggeredBy.email> , but there is no way to resolve that email to a Slack user ID for tagging. A built-in Harness expression/function (e.g., <+slack.lookupByEmail(<+trigger.committerEmail>)>) that resolves an email address to the corresponding Slack user ID, enabling proper <@SlackUserId> mentions in Slack notification templates would be really helpful here. We want to avoid going the route of doing all of it in a custom bash template.

If the Terraform plan fails, the pull request is not marked as a build failure. This introduces a potential risk, as an approver may inadvertently approve the PR, allowing invalid infrastructure code to be merged into the develop branch.

When using a connector to an AWS Secrets Manager, it would be extremely nice to be able to add a set of tags that get applied to secrets in AWS. This would make it much easier to figure out from AWS when a secret was still being referenced in Harness (and where it's being referenced).

Some pipeline failures occur during validation or rendering for example, invalid YAML or unresolved expressions before execution starts. These failures do not generate console logs, so they cannot be captured or sent to external systems like Splunk. We need a way to expose these errors in logs or via API so they can be monitored and ingested like runtime failures.

Hi Team, Good Day! At the template level, the multi-service selection option is available under the Deployment stage, however, when we attempt to configure this at the pipeline level or input set level, the UI and YAML do not allow selecting multiple ECS services — only a single serviceRef can be provided under spec.service, with no option to switch to spec.services (multi-service) from the input set. Please provide guidance on the supported approach to achieve multi-ECS-service deployment. https://app.harness.io/ng/account/iT5C2SaoSbi_31HYqXYfTA/all/orgs/ACITCustomerDigitalTeam/projects/ACITCCT/pipelines/featureecsdeploytest/pipeline-studio/?storeType=REMOTE&connectorRef=account.acdevopsgithubharnessconnectorssh&repoName=ac-it-customer-digital-harness-templates&branch=main Thanks, Amanulla

we need to OIDC option alibab acloud with using ACK cluster with Harness pipeline

When configuring the Istio Traffic Routing step with multiple route rules (e.g. a URI prefix and a header match), Harness generates each rule as a separate HTTPMatchRequest entry in the VirtualService YAML. Per the Istio spec, separate entries under match: are evaluated as OR conditions. There is currently no way to combine multiple rules into a single HTTPMatchRequest entry, which Istio would evaluate as AND. This affects the Canary Deployment step, Blue Green Deployment step, and the standalone Traffic Routing step. What Harness currently generates (OR logic): http: - match: - headers: my-header: regex: . some-value. - uri: prefix: /some/path The hyphen before uri: makes it a second list item, Istio treats this as: route if the header matches OR the URI matches. What is needed (AND logic): http: - match: - headers: my-header: regex: . some-value. uri: prefix: /some/path Without the hyphen, uri and headers sit in the same match block, Istio treats this as: route only if the header matches AND the URI matches. Why this matters: When teams need fine-grained traffic control, for example, routing based on both a path and a header simultaneously, OR logic makes it impossible to target a specific subset of traffic accurately. Any request matching just one of the conditions gets routed unintentionally, leading to unpredictable behaviour. Ask: Support AND match logic when multiple route rules are configured, either via a toggle (e.g. "Match All" vs "Match Any") or by grouping rules within a single HTTPMatchRequest. This is needed across the Canary step, Blue Green step, and Traffic Routing step.