Feature Requests

Currently, there is no way to view all feature flags, their status, activity, etc across projects. The rollout board and environments tab can show feature flags for that project, but leadership would like visibility across all apps for a more birds-eye view of feature flag utilization. This would be useful to integrate into the Harness reporting capabilities.

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.

Harness's gitsync offering is too basic. It had everything for the payload in a single file. It introduced challenges for us for how to separate by environment because all the environment info was in the same file as well (so we could commit changes to CI without it impacting QA or prod yet). We also couldn’t see an easy way to separate workspace setup from individual flag management. So thinking more that, some hierarchical file approach would make more sense so it isn’t a giant blob. We would want those separated so devs aren’t accidentally impacting something they shouldn’t because they were confused what an element was in the file. We do fully understand that approach would overwrite things done in the UI. So I think ideal state is either a 2-way sync like Harness used to have for their CI/CD pipeline stuff OR simply managing specific things via Git and the APIs vs. other things in the UI. For example – flag creation and properties in Git, but flag enablement in the UI so non-engineers can do that work. Still working through what this might mean and other challenges it would bring up, so we don’t need to do it now. But keeping engineers in their normal work area without having to give them direct access to the UI for edit purposes is appealing."

Currently, the "Traffic Type" selection dropdown (used during feature flag/split creation) defaults to a blank state or follows a strict alphabetical sort. We would like to be able to choose which one the "Traffic Type" selection dropdown defaults to so we can save time when creating a new feature flag.

Add the ability to search or filter feature flags in the UI based on targeting criteria used in their flag definitions (e.g., attribute name, operator, or value).

https://github.com/splitio/python-api does not provide a way to set a timeout for requests, and the underlying library (requests) doesn't either so it will wait indefinitely and can hang customer automations

From the customer: In terms of permissions I've seen there are 2 roles Editor Viewer I was looking for an option to define the configuration for those roles My idea is to grant limited access to specific users. To have limited access (enable/disable flags, manage rollout percentages).

The team would like to have their own custom status labels and flow. The ones we have are not all relevant to them, and custom ones would help with their lifecycle management.

Add search functionality in the FME Settings lists below: Projects API Keys SDK Keys Environments Traffic types Enhance the sorting functionality to sort the entire list of items, rather than just the current page of items.

Thinking here about disaster recovery situations or human error using the API, causing a major impact to our platform. We would like to be able to restore the feature flag env values to a previous point in time.