How to roll out a custom software feature with a flag
After user acceptance testing, a feature flag lets a small group use the new behaviour first, then widens or closes from the errors and the support load, without rolling back the whole release. Scope change says who may approve a change to the spec. Cutover says the order of the first move into production. The rollback plan says how to revert a release. This note says how a feature already in production is opened to only some people.
On this page
- Keep the flag apart from change control, cutover, and rollback
- The flag is another path in software that is already deployed
- Name the first group as overrides
- A percentage is a figure the company writes down
- Look at errors and support load before widening
- Closing the flag does not revert the release
- On a failed evaluation, return the default that was written
- The rollout starts when the list, the proportion, the watch, and the closer are written
Keep the flag apart from change control, cutover, and rollback
Scope change answers whether the spec changes and who may accept that change. Cutover answers the order on the night production is switched, who does each step, and what sends the work back to the old environment. The rollback plan answers which symptom starts a revert, who decides, and whether this revert restores data or takes back the whole release. User acceptance testing answers whether the owner produced the result on the list. The feature flag answers a different question: acceptance is signed, the code is already in production, who the new behaviour applies to first, and how that scope is pulled back without reverting the release. See How to control scope changes in custom software, How to cut custom software over to production, How to write a rollback plan for custom software go-live, and How to run user acceptance testing for custom software.
Delivery still sits under Custom software, websites, and applications. The cover of the flag record names the feature, the flag key, the default value, and where the record is kept. A sentence on the acceptance list is not rewritten as a rollout percentage. If the spec still has to change, that returns to the change record. The screen just seen in the rollout meeting is not written into the rule.
The flag is another path in software that is already deployed
The OpenFeature glossary, read on 29 October 2026, shows no publication date. It defines a feature flag as a mechanism that lets an application author define an alternative code path inside software that is already deployed, and choose that path at runtime from a set of rules. It says a flag is a single pivot of logic, with a type such as string, boolean, or json, and that a flag key is the string that identifies one flag. The name redesign_enabled on that page is an example. It is not this project's flag key.
The same page describes evaluating a flag as retrieving the value in full, including the value resolved from a configured provider and a fall back to the caller's default when execution is abnormal. A flag management system is the source of flag values and rules. It may be a vendor service, an in-house system, or an open-source implementation. This record does not name a product to buy. A rule is the criterion that assigns a variant. A variant is a semantic name for a value, and the value matches the flag's type.
Name the first group as overrides
The OpenFeature evaluation context, read on 29 October 2026, shows no publication date. Section 3 is marked hardening. It says the evaluation context supplies ambient information for flag evaluation and may be the basis of targeting, including rule-based evaluation, overrides for specific subjects, or fractional evaluation. Requirement 3.1.1 says the evaluation context must define an optional targeting key, a string that identifies the subject of the evaluation. The key uniquely identifies that subject, an end user or a calling service. A provider may require the field for fractional evaluation, for rules, or for overrides aimed at specific users. If the key is missing at resolution, such a provider may behave unpredictably.
The named group is those overrides. Each row has the targeting key, the flag key, the variant to return, and who added the person on which day. An account with no targeting key does not join the list. Until the list has a row, a percentage rollout has not started. Adding or removing a person changes the list. It does not require another release.
A percentage is a figure the company writes down
The glossary describes fractional evaluation as resolving the flag pseudorandomly from a context property, such as the targeting key, according to a configured proportion or percentage. The page uses 50/50 as its example. That split belongs to the example. It is not the proportion this rollout has to use. When the feature is to go beyond the named list, the flag record states the proportion, the context field it uses, who agreed, and the day it takes effect. A proportion with no date is not applied.
The evaluation context may include the user, the application, the host, or other ambient data. The section's examples include rules that return a value from an email address, a locale, or the time of day. If the company wants a rule on department or region, it names that field in the context and says how it is used with the targeting key. Saying that some people can have it first does not replace the row. Without a stable targeting key, the section says the provider may behave unpredictably, so this rollout stays on named overrides and does not use a percentage.
Look at errors and support load before widening
The glossary defines a tracking event as a user action or an application state that stands for a business outcome, identified by a unique string and recorded with the tracking API. The page does not say which errors to count, and it does not set a ceiling on support load. The rollout record has two further fields: which error log to read, which support queue to read, and which past period to compare. Until those fields are dated, the proportion is not raised and the named list is not enlarged.
The comparison is written on the same row: whether errors rose, fell, or could not be told apart, and how many items are countable on the support queue. The count comes from the tickets on that queue. It is not estimated. If the count passes the line the owner has written and dated, the rollout stays at the current list or the current proportion. The page does not supply that number. Until the line exists, "it seems fine" is not a reason to widen.
Closing the flag does not revert the release
The glossary says the other path sits in software that is already deployed and is chosen at runtime by the rules. Setting the variant back to closed, or removing the proportion and the overrides, means the next evaluation does not take the new path. That step does not require the codebase to be released again. Reverting the whole release, and restoring data, stays with the rollback plan. See How to write a rollback plan for custom software go-live.
The person who may close the flag is named on the record. That person may also be the person who may widen it. The two signatures stay in separate fields. Closing the flag records whether it applies to every subject or to the remaining proportion, the time it takes effect, and which row of the error log or the support queue it answers. The reason is not a blank "close it for now". Without that signature, the person on duty does not change the rule.
On a failed evaluation, return the default that was written
The OpenFeature flag evaluation API, read on 29 October 2026, shows no publication date. That section is marked stable. It says the evaluation API evaluates flag values without depending on a particular control plane or vendor. With no provider, the no-op provider returns only the default value supplied by the caller. Requirement 1.3.1.1 says the client must provide typed evaluation methods whose parameters include a required flag key, a required default value, and an optional evaluation context. The default may be a boolean, a number, a string, or a structure.
The same page says an evaluation call must not abort with an exception, and that abnormal execution must return the default value. A value whose type does not match the expected type is also abnormal, and the default should be returned. The company writes this default as closed, and dates it, so a failed evaluation does not open the feature to everyone. A blank default means the flag does not start. The default is not written as "keep the last successful result" unless another row says the provider can do that and someone has signed. The page requires the caller's default.
The rollout starts when the list, the proportion, the watch, and the closer are written
A blank flag key, a blank default, a named list with no targeting key, or no person who may close the flag means this feature is not opened to users in production. A signed acceptance test shows that the scenarios on the list were exercised. It does not fill these fields.
Three checks show the rollout is being managed: the live scope is a named override or a dated proportion; the errors and the support load before any widening are on the same row; and closing the flag changes the rule without reverting the release. A blank item leaves the flag at the written default. People outside the list do not receive it.