Targeting Feature Flags Without Losing the Plot

#dotnet #featureflags #csharp #azure

A boolean feature flag is easy:

{
  "FeatureManagement": {
    "NewFeature": true
  }
}

Then someone inevitably asks:

"Can we turn it on just for QA?"

Welcome to targeting filters.

Microsoft.FeatureManagement includes a built-in TargetingFilter that can target individual users, groups, percentage rollouts, and exclusions. Powerful? Absolutely. Slightly more complicated than flipping a boolean? Also absolutely.

The JSON Way

With plain configuration, you can define a targeting filter directly in appsettings.json:

{
  "FeatureManagement": {
    "NewFeature": {
      "EnabledFor": [
        {
          "Name": "Microsoft.Targeting",
          "Parameters": {
            "Audience": {
              "Users": [
                "qa@mydomain.com"
              ],
              "Groups": [],
              "DefaultRolloutPercentage": 0,
              "Exclusion": {
                "Users": [
                  "another.qa@mydomain.com"
                ],
                "Groups": []
              }
            }
          }
        }
      ]
    }
  }
}

This is perfectly valid. It's also the point where appsettings.json starts getting messy. The targeting filter supports:

Specific users — Enable a feature for selected individuals.
Groups — Target teams or predefined audiences.
Percentage rollouts — Gradually expose a feature to a portion of your audience.
Exclusions — Explicitly prevent certain users or groups from receiving the feature.

Exclusions take priority over the other targeting rules. For developers, this is all fine. For someone from Product who just wants to enable a beta feature for QA? Maybe don't hand them the JSON.

Azure App Configuration

This is where Azure App Configuration steps in. Instead of editing JSON, you get a UI for configuring flags and their filters. The Azure portal's Feature Manager lets you configure targeting with included and excluded users, groups, and percentage rollouts.

So instead of:

Please don't break the JSON.
Commit the JSON.
Deploy the JSON.
Explain why you put a comma there.

You get an actual feature management interface. Of course, now you're using Azure App Configuration. That's not necessarily a bad thing. If you're already heavily invested in Azure, it can be a sensible choice. But what if you just want a UI for managing feature flags without adopting another piece of the Azure ecosystem?

FeatureFlags.app

That's the problem FeatureFlags.app is trying to solve. The targeting filter provides a straightforward UI for the common case: turn a feature on for these users and keep it off for those users. In the UI, you select the Targeting Filter, add target users, and optionally add excluded users.

Your application still uses Microsoft's feature management libraries underneath, so your application code doesn't need to learn a new feature flag religion. Piece of cake. You can also define more complex filters through JSON when you need additional flexibility.

Which Approach Should You Choose?

It depends on what you're trying to accomplish.

Approach	Best for
`appsettings.json`	Small apps, developers, simple configuration
Azure App Configuration	Azure-heavy environments and centralized configuration
FeatureFlags.app	.NET teams wanting a focused feature flag management UI

The targeting logic isn't the difficult part. Microsoft has already done that work.

The real question is where you want to manage the configuration.

If you're happy editing JSON and deploying configuration changes, stick with JSON. If you want centralized configuration as part of your Azure environment, Azure App Configuration is a reasonable choice.

If you want a focused UI for managing .NET feature flags without turning the whole thing into an Azure architecture project, take a look at FeatureFlags.app.

Your feature flag system should be just complicated enough to solve your problem.

Not complicated enough to become one.