Feature Requests

Currently, when triggering a pipeline execution in Harness, the input fields (runtime inputs form) are only displayed when the "Console View" option is unchecked/disabled. Users must switch to the Pipeline (graph) view to see and fill in the execution input form. Current Behavior: When Console View is OFF: The execution input form popup is displayed, allowing users to enter runtime inputs before execution When Console View is ON: The input form popup does not appear; users are taken directly to the log-focused Console View layout Requested Enhancement: Provide an option to display the execution input form as an overlay/popup even when Console View is enabled. This would allow users to: Enter runtime input values through the familiar input form Automatically proceed to Console View after submitting inputs Maintain their preferred Console View setting without having to toggle it off just to access the input form Use Case / Business Justification: Users who prefer the Console View for monitoring pipeline execution currently have to manually disable Console View, fill in inputs, and then re-enable it (or navigate back) This creates extra steps and friction in the workflow Many users prefer Console View for its log-focused layout but still need easy access to the input form during execution triggers Proposed Solution: Add an option (either as a user preference or pipeline setting) to show the input form overlay regardless of the Console View toggle state. After the user submits the inputs, the execution would proceed and display in Console View as expected.

We need label injection within the Rolling Deploy step itself, so that the label is included in the pod template as part of the same manifest/application operation. Label to be injected:- harness.io/track : stable

Enable PAT-less authentication to the Harness API (either direct integration or through MCP) that supports On-Behalf-Of (OBO) so downstream API calls preserve the end-user identity, entitlements, and audit context. The current service account approach is not acceptable due to permissioning, auditability, and operational risk. Problem: Today, accessing Harness programmatically typically relies on: Personal Access Tokens (PATs), which introduce token lifecycle/rotation risks and are not ideal for enterprise controls; or Service accounts, which collapse user context and can lead to over-privilege, weaker auditing, and governance friction. We need a solution where: Calls to Harness are performed without PATs, and Each request is executed in the context of the initiating user (OBO), so authorization reflects that user’s permissions and is audit-friendly. Goals Provide a PAT-less authentication mechanism for Harness API calls Support OBO / delegated authorization so Harness actions reflect the real user Improve audit trail fidelity (who did what) and reduce over-privileged service accounts Enable integration via MCP (or equivalent broker) with standardized auth propagation

When using selective stage execution in a DAG-enabled pipeline, running a single dependent stage fails with a dependency configuration error if its dependsOn ancestor stages are not included. Currently, the only workaround is to include all upstream dependency stages, which defeats the purpose of selective execution. Can we add support for Selective Stage Execution in DAG-Enabled Pipelines?

For accounts with a single SAML provider configured and local login disabled, visiting an unauthenticated Harness link currently shows a login page requiring a manual "Sign in with SSO" click before the SAML request is sent, even though there's no provider choice to make and no credential prompt occurs once clicked. Please auto-initiate the SAML request immediately in this configuration and return the user to the originally requested page after login, instead of stopping at an interstitial login page. This matters for teams linking directly to Harness pages from an internal portal or docs site, where every link should land the user on the target page in one click.

When a GitHub branch is deleted, GitHub sends both a delete event and a push event with "deleted": true in the payload. Currently, Harness activates a push-based trigger for the push payload which is coming from a branch deletion event that is resulting in an unintended pipeline execution. Can we check the possibilities of enhancing the GitHub trigger handling to recognize branch-deletion push events and prevent the push trigger activation, without requiring users to add custom payload conditions such as <+trigger.payload.deleted> != true. The existing dedicated Delete event configuration should be sufficient to control branch-deletion-triggered executions.

Right now, the only way to remove data from a specific pipeline execution is to delete the entire pipeline, which takes all execution history with it. There's no way to target just one run This comes up when something accidental ends up in an execution's logs or inputs/outputs, like a value that wasn't marked as a secret and so wasn't masked. It'd be great to have a way to delete a single execution's data on demand, without having to sacrifice the rest of the pipeline's history to do it

When using the native Email Notification step, the step fails if one of the configured user groups in toUserGroups has no users — even when the step is set to fireAndForget: true. Customer has use cases where a user group may temporarily have no users, and in such cases the step should gracefully skip without failing the pipeline. Please add support to handle empty user groups gracefully in the Email Notification step.

Problem: Currently, Harness Resource Groups support "By Tag" for Pipelines, but this option is not available for Catalog (IDP) entities. Request: Add a By Tag option for the Catalog resource so access to IDP entities can be managed based on tags.

Customer requires the ability to mark the default Comments field as required in Harness Approval steps, ensuring comments are always captured when approving production deployment gates. Currently, the Comments field is optional and cannot be enforced. Please add an option to configure the existing Comments field as required in the Approval step.