Feature Requests

Dashboard is unable to show the ChangeReuqest number ( service now) which was entered by user as a parameter during production deployment. we need to way to store all the change request which were approved before production deployment

In parent build history the user is not able to see the Git hash in the failed pipeline. The parent dashboard is directing the user to check the child pipeline for git hash. This only happens for the failed pipeline, for the successful pipeline the parent shows the proper git hash

In Harness on the search navigation on the left hand side bar where you change projects/orgs it would be handy if you can right click on a project/org and open in a new tab/window. Currently the browser (Chrome & Edge I tried) doesn’t allow you to.

USCIS is requesting for Harness SMP to also support Istio in Ambient Mode to enable lighter, more efficient service mesh deployments in EKS. Our understanding is that currently Harness SMP is only supporting Istio Envoy Gateway. Istio in Ambient Mode eliminates the need for sidecar proxies, reducing resource consumption and operational complexity. Adopting Istio in Ambient Mode also aligns with industry trends and enhances Harness’s value for EKS users. Enabling Istio in Ambient Mode will help USCIS and other Harness SMP customers optimize their cloud infrastructure and accelerate application development. It is our understanding that Matt Moran from Harness already opened a Harness internal ticket number CXE-2231 related to this USCIS request. USCIS Git Issue Ticket # for this request is 198

Previously it was possible to see the git tags that triggered a pipeline in the executions screen but this seems to have been removed in a recent update and is only visible if executions are rerun manually. You are still able to filter by the tags so the data is there it just seems to have been inexplicably been hidden.

Description: Customers using Bitbucket version modules via Git tags, but Harness doesn’t currently support Bitbucket triggers for tag/release events. Because of that, IaCM Module Registry can’t auto-sync new module versions when tags are created. Request: Add Bitbucket tag/release trigger support (webhook/event type) so module registry versions can auto-sync immediately when new tags are pushed. Workaround today: Cron/scheduled sync, but customers want event-driven sync for reliable migrations.

There are currently multiple friction points with the existing matrix interface in a pipeline execution if an execution has several instances in a matrix: Matrixed stages still show in the execution even if they are skipped entirely. No way to hide matrixed stages from users. No way to minimize matrixed stages entirely by default when opening an execution.

PROBLEM STATEMENT Current Behavior: When new teams onboard to Harness, administrators must manually: Create team in Harness (User Groups) Add team members one by one Assign roles/permissions manually for each resource (projects, pipelines, environments) Repeat for every new project or org the team accesses Business Impact at PayPal: Onboarding a single team takes 1-2 hours of admin time Human error leads to incorrect permissions (too permissive or too restrictive) Teams wait days for access while admins work through backlog No standardization—each team gets different permission sets based on who configured them Compliance risk: overly permissive access granted by mistake Scaling issue: PayPal has 400+ teams, manual provisioning doesn't scale Who is Affected: Platform administrators (DPP team) managing RBAC New teams onboarding to Harness Existing teams expanding to new projects/orgs Security/compliance teams auditing access REQUESTED SOLUTION Automated Team Provisioning: Define "team templates" with default role assignments When new team is created (or synced from external system), automatically: Provision the team as a Harness User Group Assign default roles based on team type (Developer, DevOps, Admin, ReadOnly) Grant access to appropriate projects/orgs based on rules Set up default notification preferences

PROBLEM STATEMENT Current Behavior: Harness currently displays banners at the top of the UI to communicate system-wide messages (maintenance, downtime, feature announcements). According to Harness documentation, a maximum of 5 banners can be active simultaneously. These banners: Appear as fixed, full-width horizontal bars at the top of the screen Remain persistent until dismissed or disabled Reduce the visible viewport area for pipeline execution views, logs, and dashboards Stack vertically when multiple banners are active, significantly reducing usable screen space Business Impact at PayPal: With 5 active banners, critical pipeline information (build logs, test results, deployment status) is pushed below the fold Users with smaller screens (laptops, split-screen workflows) lose 20-30% of viewport height During incidents or maintenance windows, multiple concurrent banners create severe UX degradation Platform administrators hesitate to post important announcements because they know it will disrupt developer workflows Who is Affected: All 10000+ PayPal development teams using Harness CI/CD Platform administrators who need to communicate system-wide messages DevOps engineers monitoring pipelines during incidents Teams working with split-screen or smaller displays

Currently, release notes and RSS feed updates are often published after a release has already been deployed to Prod1. For customers who rely on release notes as an early warning system, this timing limits their ability to prepare for UI changes, behavioral updates, or regressions. When changes reach production before documentation is available, it creates operational risk for large enterprises that need to proactively communicate with internal stakeholders. Requested Enhancement: Leverage the existing Harness custom banner functionality to provide advance release notifications at least 24 to 48 hours before a release is deployed to production. Suggested Capabilities: Publish release notes and RSS updates before Prod1 deployment Provide a pre-release notification banner within the Harness UI Offer an opt-in early notification subscription for upcoming releases Include high-level summaries of UI changes, API changes, and behavioral updates This will give Enterprise customers time to notify internal teams of upcoming changes, validate automation or workflows that could be affected, prepare support teams for potential questions, and review UI changes before they impact end users. Advance notification would reduce friction during releases and help customers manage stakeholder expectations more effectively.