Feature Requests

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.

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.

Since the migration to app.harness.io , the Split Terraform provider https://github.com/davidji99/terraform-provider-split no longer will work. We need a way to get configuration as code supported for FME resources.

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

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.

The team would like to be able to enforce tags (e.g. require at least one tag when creating flags) and also edit/manage tags (e.g. pre-populate tags in admin settings for team to use). Due to the # of flags they plan to use, tags will be the key way to keep track of them.

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

We have a requirement for a formatted text field capability within the Harness UI. This is needed as part of our initiative where we have a need to capture the recovery actions required per step in the process, so they can be easily followed by colleagues during disaster recovery events and tests. Currently the DR steps are stored in a document and we’re looking to replace this document with a pipeline which comprises of mixture of manual and automated steps. Once the pipeline is in place, that will be the standard way the DR process will be carried out (and maintained). However, we also require a manual fall back position where the application can still be recovered if Harness is down, or an issue prevents the users from accessing Harness, or (for some reason) the pipelines cannot carry out the automated tasks. To do this, the plan is that each stage (manual or automated) would still document the steps required to carry out that step in the DR Process (in a specific stage input variable). Any time a change is merged into the main branch, a process would be kicked off to extract the documentation in the pipeline and regenerate the manual document. In addition, for manual DR steps, the documentation would be displayed on the Approval Step for the appropriate staff to follow (without having to refer to any external documentation). They then approve the step once they have completed all the required tasks. For the documentation to be easily read/understood either in the created document, or the Approval steps, we need to be able to format the text. While it is possibly to format the string variables directly in the yaml, there’s no guarantee what experience out customers will have with yaml, and obviously the direct yaml editing does not provide any of the safeguards the UI provides. While we’d love to have a fully formatted text capability, at a basic requirement level we’d like the users to be able to provide string inputs, via the UI, which can be split over multiple lines. This should allow an expanded view if required i.e. in a similar manner to script definitions where you can open in a larger window for editing.

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.

Dev team prefers to receive alerts via Slack or other method instead of emails, so would like a webhook so they can send alerts wherever is needed. They plan to monitor performance metrics quite a bit, so this would be of great value to the team.