I think most would say that’s configuration, not feature flags. The differences can be subtle but I at least don’t think they’re the same thing

That seems like code which should check customer account information, not a feature flag thats turned on or off.

Activating only for beta users or opted-in users is a supported use-case on OpenFeature using the dynamic context (https://openfeature.dev/specification/glossary#dynamic-conte...).

If your goal is to end up with the flag enabled on all requests, the only difference is the rollout strategy. You can prioritize accounts, manually enable things with one customer that you know likes to test your alpha features, and so on.

Flags at this level are not simple toggles, they will embed some business logic - that's the custom logic and attributes that I mentioned. This is standard fare in Statsig, Split, Launchdarkly, and most other commercial providers. You then collect metrics for each group to monitor features.

You use these to manage gradual rollouts, or phased rollouts by customer segments, and to run A/B tests on smaller cohorts.