Toggle Categories
FeatureSignals classifies feature flags into four categories based on how long they live, how dynamic they are, and which teams typically manage them. This classification is inspired by Martin Fowler's Feature Toggles taxonomy.
The Four Categories
| Category | Lifespan | Dynamism | Typical Owner | Example |
|---|---|---|---|---|
| Release | Days to weeks | Static per deploy | Engineering | enable-new-checkout |
| Experiment | Weeks to months | Dynamic per request | Product / Data | pricing-page-test |
| Ops | Indefinite | Dynamic per request | Ops / SRE | circuit-breaker-payments |
| Permission | Indefinite | Dynamic per request | Product / Sales | premium-analytics |
Release Toggles
Release toggles decouple deployment from release. They let your team merge incomplete or risky features into main behind a flag and enable them when ready.
- Default staleness threshold: 14 days
- Set an
expires_atdate at creation time - Remove from code immediately after full rollout
- Keep the number of active release toggles small — each one is temporary technical debt
Experiment Toggles
Experiment toggles drive A/B tests and multivariate experiments. They route each user to a variant using consistent hashing.
- Default staleness threshold: 30 days
- Always pair with impression tracking to measure outcomes
- Use mutual exclusion groups to prevent experiment interference
- Archive (don't delete) after experiment concludes
Ops Toggles
Ops toggles control operational aspects of system behavior — circuit breakers, degradation switches, maintenance modes.
- Default staleness threshold: 90 days
- Document the operational runbook for each toggle
- Require admin/ops role for toggling in production
Permission Toggles
Permission toggles gate access to features for specific user segments, tenants, or pricing tiers.
- Default staleness threshold: 90 days
- Use segment-based targeting rules for clean permission logic
- Pair with RBAC — only admins or sales should modify permission toggles
Setting a Category
bash
curl -X POST https://api.featuresignals.com/v1/projects/$PROJECT_ID/flags \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"key": "enable-dark-mode",
"name": "Dark Mode",
"flag_type": "boolean",
"default_value": "false",
"category": "release",
"status": "active"
}'Category-Aware Flag Health
| Category | Stale After |
|---|---|
| Release | 14 days |
| Experiment | 30 days |
| Ops | 90 days |
| Permission | 90 days |
Best Practices
- Assign a category at creation — Don't leave flags uncategorized.
- Match the lifecycle to the category — Release toggles should be removed quickly; permission toggles can live indefinitely.
- Use status to track progress — Combine category with status for full lifecycle visibility.
- Filter by category in the Flag Engine — The flags list page supports category and status filters.
- Review categories in flag health audits — A release toggle that's been around for 6 months probably needs re-categorization.