A team deploys a new approval screen successfully, but the operations department is not ready to use it until the next training session. Another feature needs to be tested with one customer before becoming available to everyone. These situations show why deploying code and exposing a capability are related but distinct decisions.
Feature flags can support that separation. They let an application choose between defined behaviours using configuration or targeting rules. Their value comes from controlled exposure and a clear recovery path; without ownership and retirement, flags can also accumulate into a confusing set of permanent branches that nobody fully understands.
Define the release decision the flag represents
Start by naming the capability and the reason for controlling its exposure. A temporary rollout, an operational stop control and a long-lived product entitlement have different lifecycles. Avoid putting all three behind an undocumented boolean simply because the implementation looks similar.
For a hypothetical maintenance portal, the team might expose a new visit-report workflow to one regional office. Specify what changes for that group, what remains shared and what evidence would justify expanding access. The flag should support a concrete decision rather than an indefinite state of “almost released”.
Microsoft's feature-management documentation describes libraries and targeting capabilities for controlled feature availability. Evaluate the facilities needed for the application and keep their configuration understandable to the people who will operate the rollout. Azure App Configuration feature management.
Choose an audience that produces useful evidence
Select the first users deliberately. They should represent the workflow and be available to report problems, rather than merely being the easiest accounts to add to a list. Include relevant differences in devices, permissions and data where those affect the feature's behaviour.
Define how audience membership is determined and kept consistent. A customer should not unexpectedly move between old and new behaviour during one task because different components evaluate the flag using different identifiers. Decide where the evaluation belongs and how its result is carried through the operation when consistency matters.
Use appropriate identifiers and access controls for targeting data. A feature flag is not a substitute for authorisation. The server must still verify that a user may perform the operation, including when a client directly requests a capability that the interface currently hides.
Design both paths as supported behaviour
Describe the old and new paths clearly enough to test them. Consider records created under each path and whether users can move between them. If the new feature writes information the old code cannot interpret, switching a flag off may not restore the previous operating state.
For the visit-report example, a new report format might require additional evidence. Decide how older screens display those reports and what happens to a draft when the flag changes. Make these transitions part of the acceptance criteria rather than leaving them to the first person who encounters one.
Keep shared business rules in a deliberate place. A flag should not quietly create two incompatible interpretations of approval authority or billing rules. Where behaviour intentionally differs, document the difference and preserve enough context to explain which version applied to a particular transaction.
Treat the off switch as a tested operational action
Decide what disabling the feature actually does. It may stop new requests while allowing accepted work to complete, or it may prevent a particular external action. A switch that removes a button does not necessarily stop a worker, scheduled process or API client from continuing the same operation.
Define the expected propagation behaviour and what happens if configuration is temporarily unavailable. Use a deliberate default suitable for the feature's risk and availability requirements. Do not describe the control as immediate unless the actual implementation and operating conditions support that promise.
Rehearse disabling and re-enabling the feature in a representative environment. Observe pending jobs, open forms and partially completed workflows. Give support a short procedure that explains what users will see and which checks confirm that the intended behaviour has taken effect.
Measure outcomes for the exposed group
Record enough context to compare the experience of users on the new path with the relevant baseline. Useful measures might include completion rates, validation failures, processing time and support reports. Keep the interpretation tied to the rollout design; a small selected pilot is not automatically a controlled experiment.
Inspect exceptional cases as well as averages. A feature can work well for most users while failing for one important permission level or data pattern. Collect reproducible examples and distinguish application defects from training or workflow misunderstandings so the next change addresses the actual cause.
Define the expansion criteria before enthusiasm for the release takes over. The team should know what evidence supports widening access, holding the current group or disabling the feature. Name the decision owner and make the operational consequences of each choice clear.
Retire temporary flags deliberately
Assign an owner and review date when creating the flag. Once the rollout is complete and the old path is no longer needed, remove the obsolete branch, targeting rules and tests that exist only for the transition. Keep the checks that protect the final intended behaviour.
Review interactions between flags. Several individually simple switches can create combinations the team has never exercised. Avoid building an accidental configuration language whose valid states are known only by one developer. Consolidate or simplify controls when their original purpose has passed.
Worktechlabs can help introduce controlled release practices into .NET delivery. Combine feature flags with recoverable deployments and useful operational signals so exposure decisions are based on the real user experience, with a tested way to respond and a clear endpoint for temporary complexity.
Official sources and further reading
- Microsoft: feature-management overview — supported libraries and feature targeting capabilities.
- Microsoft: CQRS pattern — consistency considerations when a rollout spans separate read and write paths.
