Feature Requests

Hi There, We a scheduling feature to trigger the pipeline, is there any possibility to schedule a pipeline to run at a certain period of time Previously i recieved two resolutions from harness support team Use corn job in pipeline triggers to schedule the pipeline to trigger at a certain time frame. Use sleep command in first stage till the time frame and run the pipeline from second stage. My pipeline doesn't imply on any of the above resolution. My expectation is, I will pass few inputs like day/date and time UTC, the pipeline's selective stages should only trigger at the give time frame. I request you to please do the needful at the earliest. Thanks, T. Chanakya

We would want to have a functionality to have the capability to be able to migrate a project from a specific Organization to a different Organization and be able to keep the historical data from CD build history and other modules. Or alternatively if the capability already exist, advise where and how we can do this

Currently, the product portfolio includes two distinct products: Feature Management and Experimentation (FME) and Feature Flags (FF). Each uses a different Terraform provider - FME relies on a third-party open-source provider, while FF uses Harness's native implementation. The current FME provider has limitations that prevent fully automated management cycles, specifically around API-key-to-environment relationship coverage. As such, it would be beneficial to consolidate these products under a unified IaC provider.

Currently, the Split Proxy outputs logs in an unstructured text format. This makes it difficult to differentiate between log levels (e.g., INFO, WARN, ERROR) or to extract and analyze specific log data when integrated with observability tools like Datadog. We would like the ability to configure the Split Proxy to output logs in a structured format (such as JSON). This would make it easier to parse, filter, and visualize logs in Datadog or other log management systems, improving both monitoring and debugging workflows.

Enable PL_NO_EMAIL_FOR_SAML_ACCOUNT_INVITES in this account

Currently, Split Webhooks only support authentication by embedding credentials directly in the webhook URL (e.g., https://username:password@host/path ). However, certain third-party tools require authentication via custom HTTP headers, such as Authorization headers. Adding the ability to configure custom HTTP headers for webhook integrations.

We want to be able to require Senior Leader approvals for production, allow that group of people to make changes without approval, but only for changing targeting rules once targeting rules are active. Ideally, regular folks should be able to create flags and initialize the production environment, just not "flip" them once productionized. Current state: Change approvals can be required, scoped to an environment, with either editor-chosen groups or with required groups Desired state: Change approvals can be required, scoped to an environment, with either editor-chosen groups or with required groups, but only on changes that effect treatments of "live" production flags. No one has indicate that this is a blocker, but it's definitely something wanted long term.

Requesting authentication for FME's Webhooks. Teams need to be able to pull impressions and audit logs from the platform but their security team requires authentication or a built-in form of validation.

It would be good for our team to be able to enforce standard naming conventions that make sense for our team

We should aim for parity or improvement on our competitor LaunchDarkly. LD feature flags can have boolean, number, string, or JSON return types. When you create a flag, you choose the type, and the SDK will return a value that matches that type. For example, a boolean flag returns true or false, a string flag returns a string (up to 32KB), a number flag returns an integer or float, and a JSON flag returns a JSON object or array (up to 32KB). Typed returns make it easy for developers to be confident their flag has the right values without having to wrap our dynamic config with parsing logic.