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.

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.

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.

The Jira integration is currently too limited, and they'd like to be able to configure it for more than one environment at once. They use Jira for everything, so being able to track all environments in Jira would be useful.

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.

Currently, on the segments page, it defaults to only show standard segments. A better option would be to default to ALL segment types and then be able to filter by type if needed.

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).

Current state when an approver follows a link to approve a flag change, they get lots of info: the flag name, the the environment, and any additional fields the requestor chose to fill out. We have chosen to use tags to identify what flags may be consumed by which microservice(s). We'd like to add the tags on that flag to this form for standardized, guaranteed context for approvers. That way the approver gets a better idea of the impact they're approving without having to rely on the requestor explicitly going out of their way to add in that context to the optional fields. Hopefully it's a small change!

You can currently only see segment keys in the UI or use the API to get the list of keys in a segment. However, they want to be able to download the segment keys in a more manual fashion, just as they're able to upload a CSV to a segment definition. This makes it easier to review the list and confirm it's accurate, especially for large segments or anything with a lot of keys.