Feature Requests

Allow looping strategies like matrix, repeat and parallel when invoking a child pipeline as a stage inside a parent pipeline.

We are requesting an API endpoint that returns basic user metadata—specifically name and email—to support secure and reliable integrations. Currently, user details are extracted from encoded local storage, which is not a stable or officially supported method. A standardized API will allow any organization to programmatically access authenticated user information, enabling smoother workflows, better auditability, and more robust integration with internal systems and third-party services.

The minimum pollInterval is 2m (minutes), which is too long for certain CI/CD workflows. Creating this request to lower this poll interval timing for all artifact/manifest polling triggers

Current Behavior: API /postExecuteStages: Can execute a specific stage. Requires sending the entire runtimeInputYaml payload. This defeats the purpose of InputSets, since all inputs must still be manually provided. API /postPipelineExecuteWithInputSetList: Accepts only inputSetReferences and stageIdentifiers. Always executes the entire pipeline, even if a stageIdentifier is specified. Not designed for stage-level execution. The Ask: Trigger only a specific stage in a pipeline. Reference an existing InputSet for runtime inputs. Avoid rebuilding and passing the full runtimeInputYaml. Example Goal: Instead of sending: runtimeInputYaml: | pipeline: identifier: my_pipeline stages: - stage: identifier: my_stage spec: service: identifier: my_service The customer wants to run: { "stageIdentifiers": ["my_stage"], "inputSetReferences": ["my_input_set"] } … and have the execution resolve inputs automatically from the InputSet. Impact: Current behavior creates overhead for customers with complex pipelines and existing InputSets. Inconsistent with the intended value of InputSets (avoiding re-supplying inputs). Forces additional scripting/automation outside of Harness to generate runtimeInputYaml. Proposed Enhancement: Extend /postExecuteStages to support inputSetReferences directly (along with stageIdentifiers). Allow execution of a single stage using only the InputSet, without requiring the full runtime YAML.

We need a overview dashboard to globally follow the usage of our template at Account scope in project pipelines.

A single developer can realistically be a member of two or more teams inside the same Org Tree (e.g. cross-functional contributors, contractors, feature squads). SEI must ingest, store and surface these shared developers correctly avoiding data loss, avoiding double-counting in higher-level nodes, and making the shared status discoverable in team views.

I'd like to be able to specify only a window start or only a window end in the ServiceNow approval step so that we can hold deployments until a specific start time, but allow them to complete any time afterwards.

We have set up user groups to receive notifications in the Microsoft Teams channel when approvals are required. However, it is currently not possible to approve requests directly within the Teams channel. Raising this feature request to enable approval actions via the Teams channel.

Summary: We’ve observed significant performance degradation in Harness.io dashboards when applying filters, particularly due to the large volume of data being queried. To address this, we propose an enhancement that introduces a feature flag to scope filter options based on user visibility—determined by their roles and assigned resource groups. Details & Justification: Improved User Experience Filtering large datasets currently results in slow dashboard performance, which negatively impacts usability and responsiveness. By limiting filter options to only relevant data, users can interact with dashboards more efficiently. Security and Compliance Alignment Presenting all filter options regardless of access may inadvertently expose metadata about resources users shouldn’t be aware of. Restricting filter visibility supports a least privilege model and aligns with internal security and compliance standards. Scalability and Future-Proofing As data volumes continue to grow, the current filter mechanism will become increasingly inefficient. Implementing scoped filters now will help ensure the dashboard experience remains performant and scalable. Suggested Implementation Approach A configurable feature flag could be introduced to enable scoped filters based on user roles and resource groups. This would allow organizations to opt-in without disrupting existing dashboard configurations.