Feature Requests

The various template UI's across harness do not support showing the template description other than the main template selection page. having it visible within pipeline studio would be useful for developers.

Problem: Approvers lack a single place to discover and manage their pending approvals, slowing deployments and increasing misses. Add a centralized Approvals dashboard at project and org levels to view and act on pending approvals.

Provide facility to configure smtp at Project level

Restrict sensitive harness permissions in Create Role When app team creates Harness role, Role should always prefix with “abc” (eg: abc Project Admin) If Role is created with Manager User and Invite User – Restrict the Role permission Restrict Usergroup role binding only with abc Role When app team creates Harnes User Group, they can bind Harness role only that prefix with “abc” If the User Group Role binding is created with Non abc role – block the action Restrict UserGroup SAML binding with only harness idmart group When app team creates Harnes User Group, they can bind SAML SSO group that has abc-gp If the User Group SAML SSO binding is created with Non abc-gp – block the action OPA policy that should not allow users to delete a set of variables that we are creating by default in every project, Only Admins could.

just wanted to know if we can have folder structure storage option, like currently if we want to run Dev pipeline then we need to write a word "dev" in pipeline name, instead can we have folder structure so that all dev pipeline will be moved/created in dev folder. Pipelines -> Dev -> <All dev pipelines> Pipelines -> Prod -> ALl prod pipelines

Request for bulk approval functionality to allow approvers to review and approve/reject multiple approvals simultaneously, improving efficiency for teams managing approvals during deployments.

Enabled the FF CDS_AZURE_OIDC_AUTHENTICATION for the Azure OIDC based authentication.

The GSM connector's OIDC authentication configuration uses a single gcpProjectId field for two distinct purposes: Constructing the Workload Identity Pool (WIP) path for authentication Specifying which GCP project contains the Secret Manager secrets This design prevents customers from using a centralized Workload Identity Pool in a separate GCP project from where their secrets are stored - a common enterprise security pattern where IAM infrastructure is managed centrally. Business Impact Customer Scenario: Enterprise customer with centralized IAM management IAM team controls all service accounts and WIPs from dedicated security/IAM GCP projects Multiple application teams have secrets in their own GCP projects Each team's Harness project needs to access secrets from their respective GCP project Security governance model requires central control of identity infrastructure Current Limitation: Customer must create a separate WIP in each application GCP project, which: Violates their security governance model (decentralized identity management) Creates operational overhead (WIP per Harness project/team) Prevents IAM team from maintaining centralized control

Hi, i would like to test the feature User Impersonation to test so opa policies that depends on the user group. I would like to activate the flag PL_ENABLE_USER_IMPERSONATION. Thanks in advance. https://developer.harness.io/docs/platform/role-based-access-control/user-impersonation

Problem We are currently managing multiple secrets using the Harness Secret Manager, but there is no built-in mechanism to notify teams when secrets are approaching their expiration date. As a result, secret expirations can go unnoticed, increasing the risk of pipeline failures and operational disruptions. Today, secret expiry tracking requires manual monitoring, which is not scalable or reliable for projects with a large number of secrets. Feature Request We request support for automated secret expiration notifications with the following capabilities: Automated notifications when a secret is nearing its expiration date Configurable reminder intervals (for example: 30 days, 15 days, and 7 days before expiration) Ability to customize notification recipients (PDL, specific users, or teams) Support for multiple notification channels (email and other supported channels) Use Case For projects managing a significant number of secrets, proactive notifications would help teams renew or rotate secrets in advance, preventing pipeline failures and security incidents.