Feature Request
Motivation
Users sometimes discover event types that aren’t available to them due to feature gating. While we can currently show or hide event types based on feature flags, this often leads to confusion—users frequently ask why a specific event (e.g. XYZ) is missing from the list.
Proposal
Allow each event type to define one or more (feature_flag, message) pairs. If the required feature flag is not enabled:
- The event type is still visible in the UI
- It is disabled (not selectable)
- Hovering over or clicking the disabled event displays the associated message explaining why it’s unavailable and how to gain access (if applicable)
This keeps the UI discoverable while proactively answering the “why can’t I use this?” question.
Alternatives
Document the requirements for each event type more explicitly. We already do this to some extent, but in practice many users don’t read the docs, leading to repeated questions and support overhead.
Feature Request
Motivation
Users sometimes discover event types that aren’t available to them due to feature gating. While we can currently show or hide event types based on feature flags, this often leads to confusion—users frequently ask why a specific event (e.g.
XYZ) is missing from the list.Proposal
Allow each event type to define one or more
(feature_flag, message)pairs. If the required feature flag is not enabled:This keeps the UI discoverable while proactively answering the “why can’t I use this?” question.
Alternatives
Document the requirements for each event type more explicitly. We already do this to some extent, but in practice many users don’t read the docs, leading to repeated questions and support overhead.