A supplier portal has a new delivery-price calculation. The code is deployed, but only employees can use it. In the demo, launching the feature means moving a switch. In the real product, the questions are less tidy: what happens to a saved quotation, who may widen exposure, and which price is used if the configuration cannot be loaded?
A feature flag selects behaviour without necessarily replacing the application. It separates deployment from feature launch. The flag does not answer every release question, though. Its evaluated state becomes another input to a business operation, alongside customer data and the application version.
Give the switch a specific job
A temporary launch flag needs an end condition. An experiment needs stable groups and a way to assess outcomes. An operational switch disabling expensive recommendations needs a defined fallback. Pete Hodgson’s Feature Toggles article distinguishes these purposes because lifetimes and configuration requirements differ.
A permanent entitlement to a paid capability is a different agreement. It may use similar evaluation technology, but it still requires proper product permissions. The marketing team should not accidentally change access to another customer’s records with the same controls used to expose a redesigned screen.
Not every fix needs a flag. A small change with no separate audience or launch date may be adequately handled by a normal deployment. Two behaviour paths create maintenance work immediately, even if nobody ever uses the switch to go back.
A percentage is not a safe cohort definition
Two employees of one customer may work on the same quotation. Assigning them independently can produce different prices for a shared business object. The right unit of exposure might be the organisation or the operation itself. Choose it according to what must stay consistent, not whichever setting is easiest in the dashboard.
Evaluation needs a stable identifier. OpenFeature defines a targeting key for the subject of flag evaluation; missing an identifier required by the provider can disrupt expected assignment. The standard cannot decide who that subject should be in this product.
When creating a quotation, it can be useful to retain the chosen calculation variant with its terms. A repeated request hours later should not revise an already offered price just because exposure has increased. Continuing an existing operation and starting a new one may legitimately follow different rules.
What happens without the configuration service?
Some implementations fetch values remotely; others evaluate locally cached rules. A dashboard change therefore does not necessarily reach every process at once. Support needs to see which variant and configuration revision actually applied, not merely the latest position of the switch.
The OpenFeature evaluation API uses a supplied default when evaluation fails. Choose that default according to the operation’s consequences. A universal assumption that false is safe is dangerous: for a flag named “disable sending”, false can restart an unwanted action.
Test a cold start without the provider, a lost connection after a successful update and a stale local copy. Distinguish an ordinary targeting decision from an error fallback, or apparently healthy requests may hide a broken control mechanism. Diagnostic records need not contain personal data for the entire audience.
Turning it off does not undo accepted work
The new path may have created quotations the old implementation cannot read. A background task may already be queued. Disabling the flag does not remove that state or recall an email. The portal needs a separate plan for completing existing quotations and correcting wrong prices.
Nor does a disabled flag isolate all new code. A dependency may load during startup, a schema migration may run during deployment and a worker may start before evaluating its setting. “The flag is off” is not a substitute for deployment testing.
Hiding a button is not access control either. A caller can request the operation directly. OWASP’s authorisation guidance calls for checking access to the actual resource. The server must enforce that permission regardless of what the frontend exposes.
Who may change a running product?
A flag change can affect customers as much as a new release. Production permissions, an audit record and an explanation for the change are appropriate controls. Higher-risk expansion may need review. An emergency can justify an accelerated process, not an untraceable shared dashboard account.
For delivery pricing, define the result to observe: quotations are correct, can be accepted and do not generate widespread manual repairs. HTTP error rates alone will miss a wrong price. Missing telemetry should also stop expansion; an empty graph is not proof of success.
Testing every possible combination of dozens of flags is rarely practical. Restrict supported combinations, test the current and intended configurations, and examine interactions that affect the same business journey. Reject invalid combinations rather than assuming nobody will select them.
Finishing the launch is a separate task
Give a temporary flag an owner and a removal condition. Remove the unused path and code references, check deployed versions and active jobs, then retire the configuration entry. Deleting the setting first may cause an older instance to take its default and unexpectedly revive old behaviour.
An operational kill switch can remain useful for years when its purpose and fallback are still tested. Last year’s launch flag does not become a reliable recovery mechanism merely by surviving. Once the portal’s transition is complete, its prices should follow an explainable rule rather than a forgotten configuration choice.