Targeting Feature Flags Without Losing the Plot

A boolean feature flag is easy:

"FeatureManagement": {
  "NewFeature": true
}

Then someone inevitably asks:

"Can we turn it on just for QA?"

Microsoft.FeatureManagement has a built-in TargetingFilter for this scenario. It can target individuals, groups, percentages, and exclusions. The evaluation uses a targeting context supplied by your application, so the feature manager knows who it's evaluating. Powerful? Yes. Slightly more complicated than flipping a boolean? Also yes.

The JSON Way

With plain configuration, you can define a targeting filter directly in 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 get's messy. The targeting filter supports specific users, groups, percentage rollouts, and exclusions. Exclusions take priority over the other targeting rules. For developers, that's fine. For someone from Product who wants to enable a beta feature 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 this:

Please don't break the JSON.
Commit the JSON.
Deploy the JSON.
Why did 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 very sensible choice.

FeatureFlags.app

We're trying to solve this problem without requiring the entire Azure ecosystem. The targeting filter gives you 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. The 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 via JSON if needed.

The Important Bit

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.

Microsoft.FeatureManagement gives you the engine. Azure App Configuration gives you a centralized Azure-hosted management experience. FeatureFlags.app gives you a focused UI without requiring you to turn feature flags into an Azure architecture project. And that's really the point.

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