Feature flags: Multivariate flag UI causes confusion between variant splits and release conditions
@dmarticus is already working on this.
Since Feb 12, 2026.
- Dominant language
- Python
- Stars
- 39.9k
- Forks
- 3.4k
- Avg merge
- 6h 51m
- Merged PRs (30d)
- 232
Description
Problem
The new feature flag UI for multivariate flags is confusing users. The core issue is that variant percentage splits and release condition rollout percentages are conceptually different but the UI doesn't make this distinction clear.
Example of the confusion
A user set up a multivariate flag with:
- Variants:
control(50%) andtest(50%) - Two release conditions, each targeting "All Users" at 50% rollout, with variant overrides
This resulted in:
- Condition 1: "For 100% of users, send 50% to test"
- Condition 2: Ignored because 100% matched the first condition
The edit view showed something that "looked sorta right" but wasn't configured as intended.
Proposed Solutions
Short-term: Add a condition summary
Add a full condition summary at the end of the release conditions that explains in plain language what the flag will actually do. This helps users verify their configuration matches their intent.
Long-term: Move variant splits to belong to rollout rules
Instead of having global variant percentages separate from release conditions, allow different variant splits for different sets of users within each rollout rule.
Benefits:
- Easier to read top-to-bottom
- Unlocks new functionality: different splits for different user segments
- Aligns with how other feature flag products work
- Fits nicely with the goal of running multiple experiments for the same flag
Context
The fundamental confusion is:
- Variant splits: How to distribute users among variants (e.g., 50/50 between control and test)
- Release condition rollout: What percentage of users matching the condition should get the flag at all
These are different concepts but the current UI conflates them, leading to configurations that "look right" but don't behave as expected.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.