Feature Requests

The "Potential monthly spend" column in Open and Ignored recommendations is confusing. The data shows the Current Spend. To my mind a potential spend is what you would spend after a change (logically in this recommendations page - after you implement the recommended change). Please consider changing the data shown, changing the column heading or adding a column to show the new spend you'll achieve if you make the recommended change. I would name it "Potential Monthly spend" but that heading is taken.

Customer is requesting the ability to define multiple dashboard "personas" in IDP, where the landing page layout, widgets, and data sources rendered are determined by the user's role or group assignment. Today, the IDP homepage/dashboard is a single shared layout for all users; the customer wants different developer populations to land on different, purpose-built views. Customer Use Case The customer has distinct developer groups with different tooling footprints and access needs. They want admin-defined dashboard templates assigned per persona, for example: Dev Persona A: Lands on a dashboard showing Jira widgets, Datadog plugin cards, and other integrated tooling panels Dev Persona B: Lands on a stripped-down dashboard showing only Jira — no other plugin cards or data sources visible The intent is both UX (reduce noise, show developers only what's relevant to their workflow) and governance (avoid exposing widgets/data sources a given team doesn't use or shouldn't see). Requested Capability Admin-defined dashboard layouts/templates (widget selection, arrangement, data sources per layout) Assignment of layouts to users via role, user group, or RBAC mapping Users automatically land on their persona's dashboard at login — no manual configuration by the end user (Nice to have) Per-persona theming/branding and the ability for users to make limited personal customizations on top of the assigned base layout Current Behavior / Gap No mechanism today to vary the IDP homepage layout or visible widgets by role/group. All users see the same landing page regardless of team or tooling footprint. Business Impact The customer views this as important for driving adoption across heterogeneous dev teams — a one-size-fits-all homepage surfaces irrelevant tooling for many developers and dilutes the portal's value as a daily landing page. Persona-scoped dashboards would also align with their internal governance model for tool visibility. Ask for PM Is persona/role-based dashboard layout on the roadmap? If so, rough timeline; if not, can this be evaluated for the homepage customization workstream?

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.

My request is that the information that anomaly is caused due to marketplace purchase is not been sent in Anomaly notification. What we are looking is Anomaly notification should have specified this cost is from AWS MarketPlace in the details. Why is this information do not have it in email notification and what need to be done to add these details in the email notification ?. We opened support request #115738 and they notified to open a Feature request.

plugins/cache plugins/sto plugins/s3

Hi Team, for the fresh helm release , the logs prints an error in RED that release not found. for every helm deployment, gives an error for one or other yaml validation in RED stating invalid YAML. It will create confusion among release team for any future deployment https://barclays-nonprod.harness.io/ng/account/ZjRkN2I1MTgtYjQxOS00Yj/all/orgs/awscceu/projects/mca/pipelines/mcaepsnonprodpipeline/executions/TOzyOsvTQGShRqcPcQFm4A/pipeline?connectorRef=gitlab&repoName=barclays/cctcoreeng/tools/harness-resources-iac&branch=MCADOSR-14201-non-prod-mvp&storeType=REMOTE

When a service, environment, or infrastructure is stored remotely in Git, Harness records a fallback branch that it uses to load the entity's YAML if the configured branch can't be resolved. This fallback branch is set automatically based on whichever branch was active when the entity was first created or moved to remote storage. The problem is that there's currently no supported way to update this value after the fact. If an entity was created or imported while a user was on a feature branch, that feature branch stays recorded as the fallback indefinitely, even long after it's been merged or deleted. The update-git-metadata API lets us update the connector, repo name, and file path, but not the fallback branch, and there's no UI control for it either. This matters most for production entities, where a stale fallback branch could mean Harness loading configuration from a branch that no longer reflects current state. Teams running governance or audit reviews can identify the problem but have no clean way to remediate it. The only current workaround is to move the entity from remote back to inline and then back to remote again while the desired branch is active, which is disruptive and not practical at scale across many entities. We'd like a supported way to update the fallback branch directly, ideally as an additional field on the existing update-git-metadata endpoints (and surfaced in the UI alongside the other Git metadata settings), so teams can audit and correct the fallback branch without moving entities in and out of remote storage. Use case: A governance review flags that several production environments have a fallback branch pointing to an old, merged feature branch. We want to reset these to main in place, without disrupting the entities or re-importing them.

In order to filter the production deployment pipelines in Harness, we need the filter "Environment Type" in the pipeline filters for the DORA workflow profile.

Feature request as suggest by Harness team to enable system level error retry mechanism for the below failures : - Pod eviction Failure to connect to addon client Connectivity errors between delegate and ci lite engine ref : https://support.harness.io/hc/en-us/requests/72479?page=1

repoURL: ' https://harness.github.io/gitops-helm-byoa/ ' targetRevision: 1.3.12 chart: gitops-helm-byoa The gitops-helm-byoa Helm chart does not support TLS when connecting to an external Redis instance. This forces users running TLS-enabled Redis clusters (e.g., AWS ElastiCache with transit_encryption_enabled = true) to deploy a workaround proxy in their cluster. Current Behavior The externalRedis block in the chart only exposes: externalRedis: host: "" port: 6379 password: "" existingSecret: "" There is no tls, useTLS, or insecureSkipVerify field. Pointing redisHaProxySvc or externalRedis.host directly at a TLS-enabled Redis endpoint results in an i/o timeout — the agent sends a plaintext handshake while the server expects a TLS ClientHello. Expected Behavior The chart should expose TLS options under externalRedis, for example: externalRedis: host: "" port: 6379 existingSecret: "" tls: enabled: false insecureSkipVerify: false caSecret: ""