Feature Requests

Currently, there is no way to dynamically access the input set names or identifiers that were applied to a pipeline execution. Customers attempting to use expressions such as <+pipeline.inputSets.names>, <+pipeline.inputSets[0].name>, or <+ inputSet.name > see them resolve to null. One use case is to include the input set name as part of the Artifactory repository path when storing reports from a security validation step.

Currently, Deployment templates are useful to build out logic for a swimlane not natively supported in CD. However, we are limited to Shell script steps, command steps and container steps. This request is to add support for containerized step groups (and step group templates in general) so that a broader range of step types work.

Can Harness add support for Dynamics 365? For reference, our end users are using this: https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci-framework-build-tasks and are trying to stay with our previous CI/CD solution (ADO) because of the link provided.

We document all of our policies on Confluence and would like to be able to direct our customers to this space when they receive a failure message in OPA so they can see details of the policy, its background and any exemption/resolution information

When managing Templates in Harness, users should be able to define version deprecation and expiry dates directly within the template configuration. These dates should then be automatically leveraged by the Policy Engine during the following events: Template Save (for templates consuming sub-templates) Pipeline Save Pipeline Run The expected behavior is: If a template version is deprecated, the system should prompt the user with a warning but allow continuation. If a template version is expired, the system should block the action entirely. Currently, we handle this through custom policy logic, which requires maintaining a separate data structure mapping all templates, versions, and their respective dates. This approach is manual, error-prone, and difficult to scale. Having this functionality natively supported in Harness would significantly improve template governance and compliance, reduce overhead, and ensure consistent enforcement across teams. Impact: Streamlines compliance management Reduces manual maintenance Enhances user experience with proactive prompts and enforcement

Currently Harness support custom dashboard metrics. Is it possible to get in-built Cloud Monitoring dashboard metrics as well?

Many customers have legacy CDK repos with multiple folders, each containing independent stacks (with its own cdk.json). Justification & Impact: Repeated NPM installs + multiple stack handling cause pipeline timeouts and stalls (NPM install stalls explicitly reported). Clients want standardized pipelines but blocked by Harness limitations. GitHub Actions already supports matrix/multi-stack execution—customers expect Harness parity.

We'd like the ability to edit the subject line for approval emails. Currently, we can only edit the body of the email. This makes it difficult to query and search for approval emails for some users.

I would like to be able to see the project name in addition to the project ID in the "show all" pop-up for dashboards using the Build/Repositories and Deploy explores

Harness recently introduced a new Kubernetes step called K8s Diff, which generally functions as expected. However, we've encountered limitations in environments where workloads span multiple namespaces or include cluster-scoped resources (such as ClusterRole, ClusterRoleBinding, CustomResourceDefinition, etc.). Currently, the K8s Diff step always appends the --namespace=<NAMESPACE> flag to the kubectl diff command, like so: For example, the following command is executed: ------ kubectl --kubeconfig=config diff --namespace=sysdig --filename=/opt/harness-delegate/repository/k8s/281f*********** e- ***********1/manifests-dry-run.yaml ------ This fixed --namespace behavior introduces problems in the following scenarios: Cluster-scoped resources: These are not bound to any namespace, so forcing the --namespace flag can cause validation errors or false diffs. Multi-namespace deployments: Some Helm charts or manifest bundles deploy resources across multiple namespaces. Applying a single --namespace flag across all resources can lead to incorrect or incomplete diff results. Enhancement Request: We propose enhancing the K8s Diff step by either: Automatically detecting when a manifest includes cluster-scoped or multi-namespace resources and skipping the --namespace flag in those cases, or Providing a configurable option to disable or customize the namespace behavior. This change would improve compatibility with complex Kubernetes workloads and charts, ensuring more accurate and reliable diff outputs.