Feature Requests

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.

Current use case: They are slowly rolling out a pilot for a particular feature and its affecting 5 flags. They are adding 1-2 clients to the segment each week (and all 5 flags reference that segment). They don't want to add the clients now because then those clients may see something before it is ready. They want to be able to schedule an update to the segment to add those clients in the future when they know the features will be ready. Originally submitted on 1/31/2025

Currently, if you kill a flag, the status will automatically switch to KILLED. But if you restore it, the status does not automatically change, which causes confusion. Would be helpful if Split forces you to pick a new status when you are restoring a killed flag. Originally submitted on 12/11/2024

Ability to see a list of scheduled changes in the app. Originally submitted on 6/16/2025

The team would like to be able to require more than one approvers (choose # of approvers) and get more sets of eyes on certain flag changes. Even more specifically, they would like levels of approvers (so approval required by one person, THEN a higher level approver). This is a re-submission of a previous RFE, as they wanted to add that they'd like more than just two (dual) approvals where possible. Also this is now high priority.

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

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.

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.