Feature Requests

Environments on the flag view are in no particular order making them hard to manage. On most other pages, environments are listed alphabetically which seems reasonable to me but they don't flow like we think about feature management. Most of the time, we're enabling in a lower env then elevating incrementally through environments. I want the ability to choose the display order. In a perfect world too, I want to initialized environments shown on top in my specified order while uninitialized environments are shown below in order to keep flags clean and easy to manage.

Hello, We would like to enforce a naming convention for variable creation but, we are currently unable to do so because we cannot create a policy set with a variable as the entity type. We would like to ask that you enable the feature flag PL_ENABLE_OPA_FOR_VARIABLES so that we can test our existing Variable naming convention OPA policy at the organization level by associating it with a policy set of a Variable entity type.

In many of the FME SDKs out there, there is a concept of a bucketingKey for ensuring splits evaluate to proper treatments based on hashed keys and percentage-based distributions. Ideally, this should be available in OpenFeature SDKs. A possible implementation would be to regard a certain kvp in the evaluation context to be the bucketingKey. Currently, this same principle is applied to a targetingKey; if a kvp in an evaluation context has key targetingKey, then the the provider implementation picks that value and applies to the Split native (user) key. The same principle can be applied to a kvp with key bucketingKey.

Opposite functionality of impression toggling? E.g the ability to switch off all tracking at say, account level, and choose which flags to track?

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 wants a native ability to run switch back experiments. KFC UKIs use case is where they want to run intermittent experiments say, by time of 30 minutes using their store or (possibly transactions ID) traffic types. Today, this can be achieved using clever configuration of Admin API, targeting and scheduling but without access to measurement and analysis dashboards. I dont belive this is an urgent requirement at this stage, as need to properly speak with customer on use case and timings, vs ability to build on their side.

E.g. Currently they have a “Production Approver” group that is configured as being needed to approve any change request for their Production environment. Is there a way to apply granularity at the feature flag level rather than environment level? The goals we have in mind: The Production environment to always need approval for deploying changes For some flags, to be able to override the “default” approvers with another group of approvers so that we restrict the default group only to individuals that should be able to approve those flags

More approval workflows for experiments. E.g. users who have access to create and edit experiments can only do so with an additional approval from individuals in the experimentation team.

JPMC ICB wants to have experiment granularity to the level beyond controls across 'all experiments', of, --> a user to edit Experiment X but not Experiment Y, which isn't supported today.

Enable feature Flag for Code Coverage