Feature Requests

We request the ability to use the terraform_remote_state data source to reference outputs from one workspace in another, even when these workspaces reside in different organizations, using the Harness terraform backend with IaCM.

Currently, Harness provides commit history linkage primarily for automated deployments triggered via CI/CD pipelines. However, in many real-world scenarios, deployments are executed manually—especially for hotfixes, patch releases, or in environments with strict change control processes. In these cases, the lack of linkage between manual deployments and the corresponding commit history creates a visibility gap for teams trying to audit, troubleshoot, or understand what code changes were deployed. Problem: Manual deployments in Harness do not currently associate with Git commit history by default. This results in poor traceability, making it difficult to answer questions such as: What code changes were included in this manual deployment? Who made those changes and when? Was this deployment aligned with the expected commits from the feature branch or hotfix? The lack of commit traceability increases the risk during incident investigations and root cause analyses.

We want to create workspace templates for team to use to create workspace easily for each service to bring up infra. so i need just user input for directory path when they create workspace using the created workspace template. Creating a template for a repo and one directory doesnt serves a purpose. it only give user who uses template prefilled fields with no edit options.

We are looking for IACM dashbaords which can give us information like what all resources are deployed using IACM module at project/org/account level. Ex ask - If we can get a dashboard with some of the details below, it will be great. Project A, Cloud[AWS|GCP], [Account|Project] Id, Resource Type[EC2, GCE, RDS], Resource Name, Creation Date. At the minimum, I am looking for a report for EC2 and GCP instances along their names and creation date if that can be generated.

Currently in IACM Approval stage, only 1 approval is required to run terraform apply. Therefore in our current setup, we had to introduce another Manual Approval stage before terraform apply so that pipeline will continue only after 2 approvals for higher environments. So, we need a feature in IACM Approval stage to allow multiple approvals before terraform apply.

We have some OpenTofu modules that include Harness resources we are trying to plan/apply. One of our pipelines is 50K lines of YAML which is causing OpenTofu to use over 40GB of memory. The documentation doesn't have any upper limits and we assumed this would be fine but are seeing crashes in our Runner where we are running the Plan for this. We narrowed down the issue to the diff that's happening and are currently suppressing it via a --json flag. We'd like to have the ability to suppress the diff output natively via the Harness Terraform Provider if it's over a certain amount of lines and ensure that there is documentation limit testing these kinds of scenarios.

Summary: We request the ability to hide all resource parameters on the resource tab of both workspaces and pipelines in Harness for users who have view access to these workspaces/pipelines. Details: Currently, with the existing RBAC roles, users can access the resource tabs even if they don’t have permission to access the state. This leads to potential security risks, as users can view sensitive resource parameters they should not have access to. The ability to hide these parameters would ensure better control over user access and prevent unauthorized visibility of resource details.

Currently, the harness_terraform image does not have any third party binaries included. Users rely on custom images to hae these included https://developer.harness.io/docs/infra-as-code-management/pipelines/iacm-plugins/plugin-images/ . However, this causes an overhead of creating and managing custom images and the image gets overridden at the account level. The request is to have the binaries for azcli and other leading cloud provider clis such as aws,gcp

I would like to have an Inline Backend Configuration feature in the Infrastructure as Code Management (IACM) module, similar to what is available in the Continuous Delivery and GitOps Module. This would streamline our processes and make configuration management more efficient.

Inside of the my IACM module ideally I would only see the pipelines associated with my workspaces and not any pipelines for building my application source. This would help keep things cleaner. The same thing is true in that in my build module I also would not want to see the IACM pipelines.