Toggle is a simple user-interface component for changing preferences, settings and other kinds of information. Toggles are typically used where the current state of a system function is either On or Off and where it makes sense to present that choice to users. They are better suited than radio buttons for such situations because they don’t require a user to select a default setting.

When a toggle is flipped to its On position the feature in question is enabled. When the toggle is flipped back to its Off position the feature in question is disabled. To prevent regressions it’s a good idea to perform tests with every toggle configuration you expect to release as well as a fallback configuration where the features you intend to roll out are all flipped Off.

Savvy teams view the feature flags they introduce into their codebase as inventory that comes with a carrying cost and seek to keep that stock level low by being proactive about removing toggles once they’re no longer needed. This may be done through a policy of adding a toggle removal task to the team’s backlog whenever a new toggle is introduced or by creating time bombs that will cause a test to fail (or even crash a production process) when a tagged toggle expires.

Toggle configuration can be managed via static files but this approach has some drawbacks once a project grows to scale. Modifying the configuration via these files can be cumbersome and ensuring consistency across all servers in a fleet can be difficult. In order to alleviate these issues many organizations choose to move Toggle Configuration into some type of centralized store, often an existing application DB. This usually accompanies the build-out of some sort of admin UI which allows system operators, testers and product managers to view and modify feature flags and their configuration.