Feature Requests

We would like Harness to expose two categories of execution data as <+...> expressions. Both are already tracked by Harness and returned via the API, but neither is available as an expression today, so we cannot use them in notifications or conditional logic without adding a shell-script step that calls the API. Request 1: Re-run metadata <+pipeline.isRerun> <+pipeline.rerunInfo.rootExecutionId> <+pipeline.rerunInfo.rootTriggerType> <+pipeline.rerunInfo.prevExecutionId> <+pipeline.rerunInfo.prevTriggerType> Request 2: Template reference metadata <+pipeline.template.templateRef> / .versionLabel / .templateScope <+stage.template.templateRef> / .versionLabel <+step.template.templateRef> / .versionLabel <+stepGroup.template.templateRef> / .versionLabel

Currently, when using a custom secret manager, Harness supports reading secrets but does not provide a native capability to update secrets directly within a custom secret store. To address this limitation, we are exploring the use of a pipeline that accepts user-provided input and updates secret values in the external secret store. However, there is currently no option to designate a runtime input field as a secure or masked field (similar to an HTML password field). As a result, sensitive values entered by users are displayed in plain text during input, creating usability and security concerns. Requested Enhancement: Introduce a capability to mark runtime input fields as secure/password fields, with the following behavior: Mask user-entered values during input and execution. Prevent sensitive values from being displayed in logs, UI screens, or execution details. Allow temporary or short-lived credentials (tokens, passwords, API keys, etc.) to be provided securely at runtime without requiring them to be pre-created and stored as Harness secrets. Support use cases where pipelines update external/custom secret stores based on user-supplied secret values.

We use the Upload Files runtime input step to push a large binary artifact mid-pipeline to a controlled location, then pull it back later in a downstream pipeline (for example, during an image build). Today this step caps at 100MB combined per step and 50MB per individual file, with no way to request a higher limit. We'd like a supported path to raise this limit for our account, similar to how other execution limits can already be raised on request.

### Problem When managing RBAC through account-level user groups (the recommended Terraform-managed approach), the Organization Access Control: Users and Project Access Control: Users views only display users who have direct role bindings at that specific scope. Users who inherit access through account-level user groups are completely invisible in these views, even though they have full functional access. ### Current behavior Account admin creates user group Owner_OrgA at account level Assigns role Owner + resource group RG_OrgA (scope: org + child projects) to this group Adds users Fadi and Karim to Owner_OrgA Fadi and Karim can access OrgA and its projects normally But : navigating to OrgA → Settings → Access Control → Users shows 0 users Same issue at project level within OrgA This creates confusion for org/project owners who see an empty user list despite multiple users having active access. ### Expected behavior The Org/Project Access Control: Users view should display all users with effective access at that scope, including those inheriting permissions through account-level user groups. Ideally with a visual indicator showing the access source (e.g., "via User Group: Owner_OrgA"). ### Impact User confusion : Org owners think no one has access to their org/projects Audit difficulty : Cannot quickly see who has access to a given org/project without checking each user individually at account level or using the Access Policy Analyzer Invite Collaborators dialog : The "Collaborators" count on the project card also shows 0, reinforcing the wrong impression ### Workarounds Check each user individually: Account Settings → Users → [user] → Role Bindings → Scope: All Use the Access Policy Analyzer to verify effective permissions per user Both workarounds are manual and don't scale. ### Environment Harness SaaS, Enterprise edition RBAC managed via Terraform (harness provider >= 0.38.0) Account-level user groups with org-scoped resource groups (INCLUDING_CHILD_SCOPES) ### Additional context This is a significant UX gap for organizations adopting the "user groups at account level" pattern, which is the recommended approach for scalable RBAC management. The underlying RBAC engine works correctly — the issue is purely in the UI/API responses that filter by direct scope bindings only.

Testing, need HarnessID immediately

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.

We need the ability to prevent the creation and use of PATs. Currently our users are creating custom AI tools that are using PAT to connect to admin APIs. This causes both a security concern for us, as well as production impacts by eating into the shared TPS constraints to these APIs. We would like either the ability to apply a policy to the creation feature, or an account toggle to completely turn it off. This is not functionality we want exposed to 3k+ users that have little domain knowledge with no ability to apply checks or restrictions.

Documentation for Pipeline triggers note that deleted Triggers which do not have 'force delete' enabled will result in a soft-deleted state. This means you're unable to reuse that identifier throughout the soft-delete period (6 months), worse is that you have to create a service ticket if you need to reuse a deleted identifier as you'll be unable to find where that resource is (the CLI and REST calls both expect a pipeline provided and deleted triggers are no longer attached to the pipelines) Documentation also notes that to avoid this problem you have to globally allow force delete on resources. This seems problematic as it could mistakenly cause more issues if users delete items accidentally whilst the flag is enabled. Instead - I'd love to see a resource management inventory The Resource Management inventory system should be available for administrators which lets you view items that exist and have been soft-deleted. It should allow permitted users to force delete resources in soft-delete states and it should also allow permitted users to restore soft-deleted items that were mistakenly deleted. A wonderful reference would be GCP's resource manager and how it manages projects. It allows users to shutdown projects (soft delete) view soft deleted projects and restore soft deleted projects. Thank you for your consideration!