Feature Requests

We have an audit need to attach items to our servicenow ticketing system. This is supported by the API but not harness native steps. while a scripted workaround is possible, it creates a burden on our developers.

Hi Team, Unable to adjust the schedules priority order inside as rule using terraform. we can only adjust using manually. We need support to set the order priority of scheduled inside a rule as well. Sample terraform code rule with 4 schedules. these 4 schedules are added randomly. Please refer attached tf file for used terraform code for rule with 4 schedules without priority. resource "harness_autostopping_rule_vm" "aws_vm" { name = "cpms-aws-ec2-01-us-work-hours1" cloud_connector_id = var.cloud _connector_id idle_time_mins = 5 filter { vm_ids = [ "i-xxx" ] regions = [ "us-east-2" ] } dry_run = false } Priorities test resource "harness_autostopping_schedule" "MondayThroughFridayUptimeFrom9amTo6pm_vm" { name = "MondayThroughFridayUptimeFrom9amTo6pm_vm" schedule_type = "uptime" time_zone = "EST" starting_from = "2025-01-02 15:04:05" repeats { days = ["MON", "TUE", "WED", "THU", "FRI"] start_time = "21:46" end_time = "22:00" } rules = concat([ harness_autostopping_rule_ vm.aws _ vm.id harness_autostopping_rule_ rds.aws _ rds.id , harness_autostopping_rule_scale_ group.aws _ asg.id ]) } resource "harness_autostopping_schedule" "twopmto3pmDowntimeOnWeekDays" { name = "twopmto3pmDowntimeOnWeekDays_2" schedule_type = "downtime" time_zone = "EST" starting_from = "2025-01-02 15:04:05" repeats { days = ["MON", "TUE", "WED", "THU", "FRI"] start_time = "14:01" end_time = "15:00" } rules = concat([ harness_autostopping_rule_ vm.aws _ vm.id harness_autostopping_rule_ rds.aws _ rds.id , harness_autostopping_rule_scale_ group.aws _ asg.id ]) } resource "harness_autostopping_schedule" "OverNightDowntimeOnWeekDays" { name = "OverNightDowntimeOnWeekDays_3" schedule_type = "downtime" time_zone = "EST" starting_from = "2026-01-02 15:04:05" repeats { days = ["MON", "TUE", "WED", "THU", "FRI"] start_time = "17:02" end_time = "18:00" } rules = concat([ harness_autostopping_rule_ vm.aws _ vm.id harness_autostopping_rule_ rds.aws _ rds.id , harness_autostopping_rule_scale_ group.aws _ asg.id ]) } resource "harness_autostopping_schedule" "CompleteDownTimeOnWeekEnd" { name = "CompleteDownTimeOnWeekEnd_4" schedule_type = "downtime" time_zone = "EST" starting_from = "2025-01-03 15:04:05" repeats { days = ["SUN", "SAT"] } rules = concat([ harness_autostopping_rule_ vm.aws _ vm.id harness_autostopping_rule_ rds.aws _ rds.id , harness_autostopping_rule_scale_ group.aws _ asg.id ]) }

WHAT Developers need the ability to test a Harness CI pipeline locally before it runs on live Harness infrastructure. WHY Today the only way to validate a pipeline is to import it into Harness and run it live — consuming delegate capacity and creating a slow iteration loop when it fails. PayPal is migrating 12,000+ developers and 7 business units from Jenkins/circle CI/Argo CD etc to Harness against a hard deadline of August 13, 2026. Every failed live run during migration adds iteration cost and slows BU onboarding. Jenkins always supported local builds before pushing a Jenkins file. The absence of an equivalent in Harness is the single biggest developer experience friction point in our migration.

We'd like for Harness CLI to support Oauth authentication instead of just API Token.

Provide native support for break‑glass admin accounts at Harness that would help: • Eliminate dependency on ad-hoc RBAC workarounds. • Improves security posture and governance.

Current Behavior: The notification channel URL field currently only accepts secrets as input expression However, in our organization, the use of secrets is restricted, leaving us with no dynamic option to configure notification channel URLs. Desired Behavior: We would like the notification channel URL field to also support Harness variables as a valid input expression , providing a viable alternative to secrets.

we need to OIDC option alibab acloud with using ACK cluster with Harness pipeline

Harness Enterprise accounts running multiple organizations — each with distinct engineering teams, security postures, and compliance requirements — have no resource partitioning at the org tier today. All platform controls are either account-wide or project-level, with no intermediate org-level tier between them. This creates real operational risk in multi-org accounts: — One org's pipeline surge can queue out another org's commits with no isolation. — A delegate misconfiguration in one org can affect all other orgs on the same account. — OPA policies cannot be scoped per org — any policy is either account-wide or per-project, with no way to match a specific org's compliance posture. — Security reviews requiring prod delegate isolation cannot be satisfied with account-wide delegate pools. — A concurrency spike in one org causes an account-wide incident affecting all other orgs. Project-level concurrency controls are not a practical substitute at enterprise scale — they require per-project configuration and do not enforce org-level resource boundaries. We need org-scoped resource partitioning controls sitting between the account level and the project level: Per-org concurrent execution quota — enforced by Harness at the platform level, not by customer configuration. Each org gets an allocated slot count that other orgs cannot consume. Per-org delegate affinity — delegates registered to an org only accept tasks from that org's projects. Cross-org task routing is not possible without explicit configuration. Per-org OPA enforcement scope — policy sets applied at org scope, not just account or project scope, so each org's compliance rules apply only to its own pipelines. Per-org rate limits and timeout defaults — org-level settings override account defaults for that org's projects without requiring project-by-project configuration. Per-org audit and compliance scope — org-level audit log filtering so each org's security team can access only their own activity without account-wide visibility. Business value: Without org-level controls, enterprise customers running multiple business units or teams on a shared Harness account cannot safely isolate workloads, enforce per-team compliance rules, or prevent one team's activity from impacting others. Every new org onboarded increases the blast radius for all existing orgs. Org-scoped partitioning enables enterprise customers to operate a single shared platform without sacrificing isolation, compliance, or stability across teams.

The Harness Enterprise plan hard caps account-wide concurrent pipeline executions at 1,000. PayPal's account is configured at 950 Addingsustomer full load to the current Harness account would breach the 1,000 cap at peak, causing widespread queuing across the entire PayPal account — affecting all BUs, not just Braintree. Customers pipeline design compounds the problem: one Jenkins pipeline per CI task (separate pipelines for linting, unit tests, integration tests) means a single code commit triggers multiple concurrent executions simultaneously. Even with consolidation, the structural demand will remain high. Braintree's target is 5,000 concurrent slots. Two-part ask: Increase the account-level concurrent execution ceiling beyond the Enterprise hard cap of 1,000. PayPal requires a negotiated contractual limit of at least 5,000 to safely absorb Provide real-time concurrency headroom via an API or Datadog metric so DPE can monitor consumption and model future BU onboarding impact before queuing occurs. URGENT — Aug 13, 2026 deadline. If unresolved, Braintree's migration creates a systemic queuing risk for all 12,000+ PayPal developers on the shared Harness account. Every minute of queuing at account capacity directly blocks developer commits across PayPal Core, Xoom, Venmo, and all BUs.

This is distinct from FR-2 (delegate health metrics at runtime). FR-11 is the identity and ownership layer: what version is running, which cluster and namespace, who owns the RBAC permissions. None of this is exposed in the current delegate UI. Practical consequences: Version mismatch failures require SSH into the pod or a Harness support ticket to diagnose. In our multi-BU environment with 7 acquired BUs (Braintree, Zettle, Hyperwallet, Honey, Venmo, Xoom, Chargehound), there is no way to see which cluster a delegate is on or which BU's namespace it belongs to. RBAC ownership is invisible — this blocks our SOD audit remediation . We need a per-delegate identity panel showing: Version — current, latest available, upgrade indicator. Cluster and node details — k8s cluster name, namespace, node name, zone. RBAC ownership — roles and bindings granting access, owners vs viewers. Assigned pipelines — which projects route tasks to this delegate. Plus a fleet inventory page with all delegates listed, all columns filterable and exportable. Business value Directly supports SOD audit remediation ( Enables self-service delegate upgrade planning across a multi-BU fleet without Harness support involvement.