Feature Requests

Allow for users other than the requestor (or admin) to edit a scheduled change. When they schedule and approve a flag change, only the requestor can modify it after it's approved. If someone is OOO, we are running into challenges updating scheduled changes.

Request for a mobile-friendly approval process. They'd like ability to approve change requests from their phones. Would need to see the diff. Trevor suggested possibly solving by including a yes/no in the email, but its important that the team can review the diff as well.

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.

Group releases together to turn on all at once (or roll back). This would be useful give the number of flags they plan to create within each release.

The ability to navigate from an experiment feature flag, to an associated experiment dashboard. Today, this can only be done from experiment dashboard, back to the feature flag.

In Get Feature flag API ( https://docs.split.io/reference/get-feature-flag ) , currently returning Owner ID, any chance you can add user email in the JSON response? It will help us reduce complexity with bunch of scripts that we are generating for flag hygiene. Currently, I am looping through user details API to get the relevant info.

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

Customer is interested in reducing the impact of a poor-performing variant and choosing a winning variant sooner rather than later.

Customer is looking to leverage the impressions webhook to create a workaround for MTK monitoring. They are concerned that without HMAC for the webhook and with the potential IP spoofing they would not be able to consume that traffic. Their request would be for security enhancements like HMAC around the webhook.