Feature Requests

Currently the GitOPs Update Release Repo step has very limited functionality. You need to declare in the advanced configuration specific values to target for updates. This limits the amount of changes you can easily make within the pipeline. I want to be able to abstract away the full gitops backend from users. I could do this if the Update Release Repo step applied a fully rendered manifest into the target manifest. Overrides already support manifests and we can put values files in overrides that are rendered by the expected hierarchical order and can be used in the K8s Rollout step. If we had this same ability in the Update Release Repo step we would be able to make complex updates to our gitops files totally in harness cleanly. I'd like to see the ability to have a manifest be rendered at pipeline runtime from manifests present in the overrides and then apply that fully rendered manifest to the target gitops file.

github connectors can be different for each environment. CD pipeline need to switch connector for each env so that it can still connect with same DBSchema but github connector expression resolved to env specific connector name

The Run Pipeline form shows "No manifest chart versions found" when the chart version picker cannot populate. This message is ambiguous -- it covers at least three distinct states: The manifest's chart version field is hardcoded (not set to Runtime Input), so there is nothing to fetch. The Helm repo is transiently unreachable. The chart genuinely has no published versions. A customer in case (1) sees the same message as cases (2) and (3) and has no way to know the root cause is their own service config. They spent an entire day hardcoding the chart version as a workaround before discovering the fix was to set the field to Runtime Input ( <+input> ). What we need When the chart version field is not set to Runtime Input, the Run Pipeline form should display a distinct, actionable message. For example: "Chart version is fixed in the service config. Set it to Runtime Input to enable version selection here." When the field is Runtime Input but the fetch fails (repo unreachable, no versions), the current error path is appropriate, but it should include a retry affordance or at least a timestamp so the user knows whether the empty state is fresh or stale. Why it matters The current generic empty state silently conflates a user-fixable config issue with a transient platform or registry failure. Customers cannot distinguish between the two without reading the service YAML or opening a support case. A targeted message would let users self-serve the fix in seconds. Use case A user adds a second Helm manifest to a service and leaves chart version hardcoded. On the Run Pipeline form the version picker is empty with no explanation. The user assumes a platform or registry problem and spends significant time debugging before discovering the field needs to be set to Runtime Input in the service config.

Recommendations workflow is clunky where I: Filter a list of recommendations that is unique to my group/platform-> Click into a recommendation-> recommendation appears within the page instead of a new tab -> I gather the recommendation then I must go back to the results filtering page to click on another recommendation. Can I suggest to open a new tab everytime I click into a recommendation. So I can preserve the filtered list whilst still being able to collate all the recommendations I need

Enhance the Harness Workspace variable management experience by adding support for descriptions on variables. This will allow users to provide additional context about the purpose, usage, and expected values of workspace variables, improving readability, maintainability, and collaboration across teams. Requirements Add a Description field when creating or editing workspace variables. Display the description alongside variable details in the workspace UI. Support viewing and updating descriptions for existing variables. Ensure descriptions are stored and retrieved through the corresponding backend APIs. Maintain backward compatibility for variables that do not have descriptions.

FME integration with Slack is missing some key pieces of info that the WorkJam team likes to see, especially those without visibility into Split's audit logs. They've previously used LD's integration, which they're used to and prefer. For example, when feature flag changes are posted to Slack, it includes details about what changed (e.g. user XYZ was added to a flag to a specific variation). For users that have access to Split, no since they can see everything anyway through the Audit logs section, however for internal stakeholders there’s no real way to see the audit trail. This is something that would be considered as a step backwards once they finalize the migration to FME from LD.

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.

We need the Playbooks feature to source control Ansible roles/code scoped from Account level rather than at Project level.

Allow the ECS Blue Green Traffic Shift step in Standalone mode to operate on the same listener rule ARN that was referenced in the ECS Blue Green Create Service step. Today this is blocked with: ▎ Invalid request: Standalone traffic shifting can't be performed on the rule specified in Blue Green Create Service step From the customer's perspective, the rule referenced in the Create Service step is just another rule pointing at the blue/green target groups. It's unclear why that particular rule is singled out as ineligible for Standalone shifting, when other rules pointing at the same target groups are allowed. The enforcement appears to assume a 1:1 Create-Service-to-rule relationship that doesn't match real-world multi-rule services. This would simplify our (and other customers using ECS deployments) steps, as right now we need a single inherit step to account for the listener rule ARN in "ECS Blue Green Create Service", followed by multiple standalone steps to account for other listener rules.

The ECS Blue/Green Create Service step should dynamically evaluate whether the green ECS service already exists and create it when absent or update it when present, rather than requiring customers to figure this out themselves. While planning a blue/green traffic shift template, we noticed the ECS Blue/Green Create Service step exposes a toggle for updating the green service. To run blue/green pipelines consistently across hundreds of ECS services without toil or bespoke scripting, the step needs to create the green service if it does not exist and update it if it does. It seems odd that Harness will manage the ECS service's config, but needs customer intervention to understand whether to create the service or not. Allowing this to be automatically managed by the step will benefit all customers using ECS deployments in Harness