Business scenarios
Release the way the business wants to
Who gets a new feature is decided by the toggle's attributes — by user, group, jurisdiction, brand, amount or anything else your application knows. Every scenario below is set up in FTF; the code stays the same.
Try it on some customers first
A share of your accounts, always the same ones — never a random pick on each visit.
Canary release
Switch the feature on for 5% of accounts, watch it, then 20%, 50%, everyone. Accounts already in stay in as the share grows.
A/B testing
Half of your customers see the new version, half the current one — always the same half. Compare the results in the analytics tool you already use.
Gradual rollout
Any share, raised step by step as confidence grows. Raising it only adds accounts; nobody who already has the feature loses it.
Pilot with a chosen group
Name who gets it first, and add the next group when the business is ready — no deployment.
By jurisdiction or state
Launch in one or two states first, where the rules or the market suit it, then widen.
By brand or line of business
One brand, or one line of business, goes first; the others follow once it has proved itself.
Named users, staff or a beta group
Your own staff, chosen users, or customers who agreed to try it get the feature before anyone else.
Business rules on numbers
A number the application already knows — an amount, a premium, a score — against a threshold or a range. Move the threshold in FTF, not in a release.
Fast-track small claims
Claims under a threshold take the new, faster path; the rest stay as they are.
Review large policies
Policies above a premium go to the new review step while it's being proven.
A band in between
Only the middle of the range gets the change — from one amount up to, but not including, another.
Reuse and combine
One target market, many features
Several features share the same audience. Define it once on one toggle; the others refer to it. Change it once, and every feature follows.
Narrow it down
Attributes add up, and all of them must hold: NSW only, claims over $10,000, and 20% of those accounts.
Launch and safety
These come from the toggle's own switch and its release, not from attributes.
Coordinated launch
The features of one release, across applications, go live together with one switch — each still with its own attributes. Releases
Kill switch
A feature misbehaves in production? Switch it off for everyone, in seconds, while the fix is made.
Dark launch
The code goes to production with everything else, switched off. Customers see nothing until the business says go.
What attributes don't do
- No "everyone except" — a list lets values in; it doesn't keep them out.
- No either/or between attributes — all of them must hold.
- No schedules — a feature isn't switched on or off by date.
- On or off — one version or the other, not several variants of a feature.
Measuring the result
FTF decides who gets which version. Measuring which version did better stays with the analytics tool you already use.
Four kinds of attribute, one call
A toggle can carry attributes; the person setting up the toggle picks each one's kind. Your code passes what it knows about the request — the state, the claim amount, the account — and the toggle is on only when every attribute matches.
List
states = NSW,VIC— matches if the caller's value is in the set.- Change the set any time; the call site never changes.
- Leave a blank in the set to let callers that don't pass a value through.
Expression
claimAmount gt 10000— equals, not equals, greater or less (or equal), between.- A missing or non-numeric value never matches.
Percentage
accountId — 20%— matches if the account falls in the included share.- Sticky, not random: the same account always lands the same way.
- Raising the share only adds accounts; nobody already in drops out.
Reference
states → other_toggle.states— reuses a list defined once.- Any toggle can be the source. Change it once and every toggle referring to it follows.