Feature Requests

Request a Harness-supported API endpoint that allows authorized automation to update an SCS license family and manage direct and indirect dependency relationships in a way that is compliant with internal firm standards (e.g., governance, auditability, RBAC, validation, and change controls). Without an API: -Changes are manual, inconsistent, and hard to govern -We cannot enforce required approval, validation, or audit controls -Dependency graph correctness drifts, increasing operational and compliance risk

support the use of secrets from other secret managers within a custom secret manager. Currently, only secrets stored in the Harness Secret Manager can be used within a custom secret manager. Since our secret xxxxx is not stored in the Harness Secret Manager, which is causing the issue.

We are integrating an infrastructure provisioning pipeline with a microservices deployment pipeline. For this flow to be efficient, the deployment pipeline must be dynamic, allowing flexible selection of which services should be deployed. Today, this requires manually creating stages for each service, which does not scale. The proposal is to allow the deployment pipeline (child pipeline) to be dynamically triggered by the parent pipeline based on a list of services, with a simple and user-friendly selection through the UI. This enables orchestrating infrastructure and deployments in a single flow, while keeping the pipeline cleaner, more scalable, and easier to operate.

I want to dynamically generate sections in the IDP workflow based on field values selected in the first title. Currently, the scaffolder doesn't support conditional logic to show or hide entire steps or sections. It would be beneficial to have this feature to enhance the flexibility and efficiency of the workflow.

When a <+secrets.getValue(...)> expression references a secret path that does not exist, Harness currently substitutes an empty or null value and continues pipeline execution without throwing an error. This behavior is silent regardless of whether the secret manager connector is configured to connect via delegate or via Harness Platform, though the Platform (cloud-side) path is particularly opaque since resolution errors are not propagated back to the pipeline at all. The expected behavior is that a missing secret should be treated as a hard failure, and the pipeline should be stopped immediately with a clear error indicating which secret path could not be resolved. This would prevent downstream failures that are difficult to diagnose, in this case, a Kubernetes Job crashing with BackoffLimitExceeded, which appears unrelated to secret resolution. Affected areas: secret expression rendering in Helm values files, Native Helm deployments, secret manager connectors using Platform-side connectivity.

This is the specific implementation ask for PayPal: AIDA has no awareness of PayPal's internal pipeline patterns, DPE runbooks, OPA rules, or the Raptor/Kraken template structure our CI/CD platform uses. When AIDA gives advice, it gives generic Harness answers that don't apply to our configuration. For SonarQube token failures, AIDA has no knowledge of PayPal's DPE-managed auth pattern. DPE's institutional knowledge in Confluence and DPEIR is completely unavailable to AIDA. We need a customer-owned knowledge base that DPE seeds and maintains: DPE uploads internal runbooks, SOPs, template docs, known-issue guides via a management UI. AIDA indexes PayPal-specific content and prioritizes it over generic Harness answers. OPA policy library awareness — AIDA understands our quality gate rules. Failure → runbook mapping: AIDA surfaces the relevant DPE runbook for a recognized failure pattern. KB management UI editable by DPE without Harness involvement or a support ticket. This must be customer-controlled, not a shared Harness KB. Business value Transforms AIDA from a generic responder into a PayPal-aware assistant. Scales DPE knowledge to 1,000+ developers without proportional support headcount growth. Addresses 54% AIDA uselessness rating.

AIDA currently reads only log text. It has no awareness of infrastructure metrics, no access to customer runbook context, and no memory of historical failure patterns. 54% of users who tried AIDA found it useless for real diagnostic scenarios (Feb 2026 survey). AIDA cannot proactively warn on resource misconfigurations before they cause a failure. We need AIDA to: — Analyze infra metrics alongside logs (not just log text) — Integrate with a customer-provided knowledge base (for PayPal-specific implementation) — Match current failures against historical patterns across builds — Perform root cause chain analysis (infra event → failure cascade → impact) — Provide proactive pre-execution warnings when resource configs are misconfigured This is the general AIDA capability improvement. FR-12 covers the PayPal-specific KB seeding implementation. Business value Converts AIDA from a log text reader into a genuine diagnostic assistant. Addresses 54% uselessness rating from our Feb 2026 survey.

using the filter "modules": ["CI"] in the API https://transunion.harness.io/audit/api/audits/listV2?accountIdentifier is nor giving any CI specific audit events. All the CI activities whatever comes under CI module in harness should be displayed when "modules": ["CI"] " filter is used with teh above API. API doc: https://apidocs.harness.io/audit/getauditeventlist

Project labels needed for perspectives and dashboards for GCP.

Can we have a feature to filter evaluation results of a specific policy?