Feature Requests

The Policy Evaluations screen currently only supports filtering by Entity Type, Action, and Status. This makes it difficult to investigate specific policy evaluations when policies are applied at higher scopes, such as Account or Organisation, where the volume of evaluation records can create significant noise. To improve usability and troubleshooting efficiency, extend the filtering capabilities to include: Organisation Project Resource Identifier / Resource Name Policy Set Policy These additional filters would allow users to quickly isolate policy evaluations for a specific org, project, resource, or policy without manually searching through large result sets. In addition, the same filtering options should be available on the Overview tab so that charts and summary metrics can be analysed against a chosen subset of data. This would enable users to view trends and policy compliance information for specific organisations, projects, resources, policy sets, or policies rather than only the overall dataset. This enhancement would bring the Policy Evaluations experience closer to the flexibility already available within the Audit Trail filtering experience, providing more targeted investigation, reporting, and operational troubleshooting capabilities.

Please enable Ansible capabilities for our account.

We need support for Large Segments on Server Side SDKs. Our customers area approaching the documented limit or 100,000 segment keys, with one already pushing past that limit to 100,013. Will there be any issues with the segment over the limit now?

Being able to copy the companies (keys) in a segment to the clipboard more easily would be great.

We have scenario about repositories type - infra that this repos not exist backend file tf cause this file's buiding in runtime pipeline in github action, we've including this file in runtime before to start terraform plan and apply.

Description When managing delegate tokens with the harness_platform_delegatetoken Terraform resource, terraform destroy revokes the token but does not permanently delete it. Because revoked delegate tokens are retained for a period of time, the same token name cannot be reused immediately. This causes a recreate flow to fail unless the user manually deletes the revoked token, waits for retention cleanup, or changes the token name. Request Add an optional Terraform setting to permanently delete a revoked delegate token during destroy, for example: hard_delete_on_destroy = true or: delete_behavior = "revoke_and_delete" Why this matters Teams managing delegates with Terraform expect a clean create/destroy/recreate workflow. Today, the revoked token state requires manual cleanup or token renaming before the same Terraform configuration can be applied again. The default behavior can remain revoke-only, but Terraform users should have an explicit opt-in option to fully delete revoked delegate tokens when needed.

We want Harness to orchestrate CodeQL scans, however this piece of documentation mentions that CodeQL scans via Harness orchestration only support typescript/javascript or python - https://developer.harness.io/docs/security-testing-orchestration/sto-techref-category/github-advanced-security/#scan However, CodeQL supports all of the following languages: C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, Rust, and Swift.

Summary: We need Harness IDP workflows to support sending custom headers, including user email, from the ValidateAndFetch field type. Currently, appendUser works with SelectFieldFromApi, but it does not work with ValidateAndFetch. As a result, workflows that use a button-based validation pattern cannot pass required user context, such as email, to backend APIs. Module IDP Category Feature Request / Enhancement Priority High

We are currently implementing Harness IDP workflows to trigger pipelines using a service account-based token for scalability and controlled access. As part of our design: IDP workflows trigger pipelines on behalf of users.We plan to use a service account token (instead of user tokens).End-user identity (email) will still be passed for auditability Current Understanding / Constraint From our discussions and previous inputs: IDP workflows can retrieve tokens only from Harness Secret Manager External secret managers (e.g., Vault) may not be supported for this use case. As per this ticket reference: https://support.harness.io/hc/en-us/requests/117235 we can only use Harness Secret Manager for Vault and not the enterprise Vault. Creating this feature request to enable the ENTERPRISE VAULT for IDP module in Harness. thanks.

Description Today, when a Harness pipeline is triggered through the API using a service account token, the pipeline execution is attributed to the service account. This is expected for automation, but it creates an audit gap for organizations where a trusted external system authenticates real users and then triggers Harness deployments on their behalf. Request: provide a supported API-level delegated attribution model for pipeline executions triggered by service accounts. The desired capability would allow a trusted service account to pass a verified end-user identity, such as an email or Harness user identifier, when calling the pipeline execute API or custom webhook endpoint. Harness would then display the execution as being requested/executed by that end user, or clearly show the execution as performed by the service account on behalf of that user. Example desired display: Executed by: user@example.com Triggered via: deployment-service-account or Executed by: deployment-service-account on behalf of user@example.com This should not simply overwrite audit history. The audit record should preserve both identities: * the authenticated automation principal/service account that made the API call; * the delegated/requesting end user from the trusted external system. Use Case An enterprise uses an external deployment portal or internal platform where users are already authenticated and authorized. That system calls the Harness API using a service account token to trigger a CD pipeline. For audit/SOX compliance, the deployment record in Harness needs to identify the real user who requested the deployment, not only the service account used by the external automation layer. Requested Behavior Add a supported field, header, or property to the pipeline execute API and/or custom webhook flow, such as: onBehalfOf requestedBy delegatedUser executedByUser The feature should allow customers to pass a verified user identity for display and audit attribution. Why This Matters For regulated environments, deployment audit records need to answer both: Which automation principal called Harness? Which real person requested or approved the deployment in the external system? Today, customers can pass the requester as a pipeline variable or metadata field, but that does not update the native Harness “Executed by” / execution history attribution. A first-class delegated attribution model would make API-triggered deployment records more useful for compliance, SOX evidence, and audit review.