Feature Requests

Current state we can provide suggested values for Semantic Versions and Strings when setting up a custom attribute in FME. e.g. "test", "testing" -- "1.0.0", "1.1.0", "2.0.0" will appear as suggested matchers when using that attribute on a flag Desired state would be that we have that option for DateTimes e.g. 3/12/2026, 12/31/2025, will appear as suggested matchers when using that attribute on a flag

This would be useful for backend SDKs during situations where a backend SDK needs to support multiple projects

Step in a pipeline that would allow you to rollback a flag change, just like you can do in CD module.

Customer is operating with more than 10k-15k kiosks around the world. They would like to use global configuration management to apply configs globally across stores, restaurants, kiosks, market level, national level, regional level etc and have one platform to manage all the configuration. The current process of managing configuration is very cumbersome and involves syncing with a local file that stays offline on the kiosk for a long time.

In the Harness feature management under a segment definition, there is currently no option to export the list of enabled ids as a separate csv file. This will be incredibly convenient given there is no easily way to obtain all ids at the moment.

The source code is available for the .NET provider, but there is no associated NuGet package, which we have for other providers. This is a blocker for their implementation, as they require this abstraction layer and use .NET.

Our security team requires that all important logs are encrypted. If we could upload a custom header/token for the audit log connection it would allow us to stream these.

Objective: Allow account administrators to configure or disable the default "Owned by me" filter on the Rollout Board to improve discoverability and reduce user confusion. Problem Statement: Currently, the FME Rollout Board defaults to the “Owned by me” filter for every user. While intended to be helpful, this creates a "cold start" problem: User Confusion: Team members navigating to the board often assume flags are missing or that the system is broken because they see an empty state by default. Onboarding Friction: As we encourage cross-functional teams to track flags through various stages, the manual step of clearing filters adds unnecessary "click-debt" to their workflow. Proposed Solution: We request a mechanism to customize the default landing state of the Rollout Board. Ideally: Global Toggle: An option to set the default view to "All Flags" (no filters) at the Project or Account level. Sticky Filters: The board remembers the user's last-selected filter criteria rather than reverting to "Owned by me" upon every new session. CSM Created JIRA for this: https://harness.atlassian.net/browse/FME-13104

Customer would like to see a dedicated notification flow to ensure the requester of a Feature Flag Change Request (CR) is automatically emailed once their request is approved or rejected. Currently, while approvers are notified of pending requests, the original author often remains unaware of the outcome, leading to "surprises" when changes go live without their knowledge. Implementing this alert will close the visibility gap and streamline the transition from approval to deployment.

Customer would like to be able to more granularly monitor their MTKs. They would like to have self-service options for getting the visibility they see from the MTK reports that we can request and share with them. Ideally they would want to be able to see MTKs broken down by flags, by traffic types, and also be able to get notified when they reach their MTK entitlement. Customer implemented pooling to be able to better control their MTKs but they are still seeing higher than anticipated volumes which is leading to a decrease in their trust of the platform and ability to predict what their utilization would be.