An override solves a simple problem: one answer is not enough for everybody.

The limit of a single answer

A feature flag is a switch that turns a feature on or off without releasing new code. In its simplest form, the switch is one answer for everyone. That is useful when you are sure a feature is ready for the whole world, and not much else. Real products have staff who must try things first, customers on different plans, countries with different laws, and old app versions that cannot display new screens.

Two separate jobs

To treat groups differently, you need to do two separate jobs. First, you must describe the group: “internal staff”, “premium customers”, “users in Canada”. That is the job of a segment. Second, you must say what the group should receive: “the feature is on”, or “the button colour is green”. That second job is the job of an override. A segment is the guest list. An override is the instruction attached to the guest list for one particular feature.

Why not just write it in code

You could write “if the user is staff, show the feature” directly in your code. Many teams start that way. But every change needs a new release, the rule is scattered in many files, and nobody outside engineering can see or change it. An override keeps the rule outside the code, in one visible place, where it can be changed in seconds and recorded in an audit trail.

Overrides sit on top of a handful of simple ideas. Let us meet each one.

Project and environment

A project is the container for one product. Inside a project there are environments, which are separate copies of your settings, such as Development, Staging, and Production. Each environment has its own switches, so you can try a change safely in one place before it reaches real customers in another.

Feature and feature state

A feature is a named switch, such as “new-checkout”. The feature state is its current answer in a given environment: on or off. The state may also carry a value, such as a number or a short piece of text, which is how a feature becomes a remote setting.

Identity and traits

An identity is one specific user as Flagsmith knows them, usually represented by an identifier your app sends. A trait is a small fact attached to that user, such as country, plan, or app version.

Segment

A segment is a named group defined by rules about traits. Someone is in the segment if they satisfy the rules at the moment Flagsmith checks. Segments are shared across a project.

Before an override can be special, there has to be something ordinary to override.

The baseline

Every feature has a default state in each environment. It is the answer for anyone who does not match any special arrangement. Think of it as the main menu. If you change nothing else, every person receives this answer.

Why the baseline deserves thought

The default is not a boring detail. It is what the majority of people will experience, and it is what everyone falls back to when something goes wrong. If your overrides cannot be evaluated for any reason, the default is the answer that appears. So it should be the safest reasonable choice.

The default is separate in each environment

A feature may be off by default in Production while on in Development. That separation is deliberate. It lets engineers explore freely in a safe place while customers see only what has been approved.

A segment override is a small, precise instruction: for this feature, in this environment, members of this segment get this answer.

Four pieces in one sentence

Every override answers four questions. Which feature does it apply to? Which environment is it in? Which segment does it target? And what answer should the members receive? Change any of the four and you have a different override.

An override is attached to a feature, not to a segment

This detail is a common source of confusion. The segment itself does not hold a list of features it affects. Instead, each feature holds a list of the segments that receive special treatment from it. When you open a feature in the dashboard, you see its overrides. When you open a segment, you see its rules. The two are connected, but they live in different places.

An override does not change the segment

Creating an override does not alter who belongs to the segment, and editing the segment’s rules does not alter what the override says. They are two independent ideas working together. This separation is what lets one segment be reused by many features, each with its own arrangement.

flowchart LR
    SEG["Segment: Beta testers (who)"] --> OV["Override (what they get)"]
    FEAT["Feature: new-dashboard"] --> OV
    ENV["Environment: Production"] --> OV
    OV --> ANS["Answer: ON with a value"]
    

An override can change the on-or-off state, the attached value, or both.

The on-or-off state

The most common override flips the state. The feature is off for everyone by default, and on for the members of the segment. Or the reverse: on for everyone, and off for a group that should be protected, such as customers with an old integration.

The attached value

If a feature carries a value, such as a number of days, a message, or a colour name, an override can supply a different value to its members. This is how one feature can show a blue button to most people, a green one to a group, and a different text to staff. Values are explored further in a later chapter.

Multivariate choices

For a multivariate feature, which offers several variations with percentage shares, an override can choose the variation for its members. Later chapters show how this lets staff always see one variation while everyone else is split.

Look closely at one override and you will find the same few parts every time.

How the parts fit

The segment is the “who”. The feature and environment are the “where”. The state and value are the “what”. The priority is the “in which order”. If you can fill in all four parts for any override in your system, you understand it. If one part is unclear to you, that is where the next surprise will come from.

Reading an override aloud

A good habit is to read each override as a sentence: “In Production, for the feature new-dashboard, members of Beta testers get the feature on, and this arrangement is third in the order.” If you stumble while reading, the arrangement needs to be simplified or documented.

The exact screens change between versions, but the sequence of ideas is always the same.

Why Development comes first

Because overrides are separate in each environment, you can build and test the full arrangement in Development without any customer noticing. Only when it behaves as expected do you recreate it in Staging and then Production. Some plans offer ways to speed this up; confirm what yours provides.

The final check that people skip

After saving, look at a real or fake identity in the dashboard and read what the feature evaluates to. This single step catches the most common mistakes: a wrong segment chosen, a value typed in the wrong box, or an override placed below a broader one that captures everyone first.

A single person can belong to several segments, and a feature can have several overrides. Flagsmith needs a rule for which one wins.

The problem of two winners

Imagine Maria is a premium customer, lives in Canada, and works at your company. She belongs to “Premium customers”, “Canada”, and “Internal staff”. If the feature has an override for each, and they disagree, Flagsmith cannot give her all three answers.

An ordered list

For each feature in each environment, the segment overrides are kept in an order. The dashboard lets you rearrange it. At evaluation time, Flagsmith walks down the list and uses the first override whose segment matches the person. Later overrides are not consulted for that person, even if she belongs to those segments as well. In most versions, the override at the top has the highest priority, but check how your dashboard presents it.

First match wins, not best match

Flagsmith does not weigh the overrides and choose the most sensible one. It does not merge them. It takes the first match and stops. This is simple and predictable, and it puts the responsibility for the order on you.

flowchart TD
    A["Person asks about a feature"] --> B{"Matches override 1?"}
    B -- Yes --> R1["Answer from override 1"]
    B -- No --> C{"Matches override 2?"}
    C -- Yes --> R2["Answer from override 2"]
    C -- No --> D{"Matches override 3?"}
    D -- Yes --> R3["Answer from override 3"]
    D -- No --> R4["Answer from the feature default"]
    

Because first match wins, the order is not a detail. It is part of the meaning.

Narrow above broad

The safest rule of thumb is to put the most specific segments at the top and the most general at the bottom. A small “Pilot customers” segment should sit above “All premium customers”. If the broad segment is first, it captures the pilot customers too, and the pilot override is never reached.

Exclusions above everything

If some people must never receive a feature, such as test accounts or customers with an incompatible set-up, give them a high-priority override that sets the feature off. Because it comes first, nothing below can turn the feature on for them.

An example in order

Consider the feature “new-reports” in Production, with four overrides. First, “Customers with legacy integration” sets the feature off. Second, “Internal staff” sets it on. Third, “Beta programme” sets it on with a special value. Fourth, nothing, because everyone else falls to the default of off. A staff member who also has the legacy integration gets off, because the first override captured them. This may be exactly what you intended, or it may be a surprise. Either way, you must decide it on purpose.

There are three levels of answer for a feature, and the more specific one outranks the more general.

Three levels

At the bottom is the feature default, the answer for everyone. In the middle are segment overrides, the answers for groups. At the top are identity overrides, the answers for one named person. In Flagsmith’s usual model, the more specific the instruction, the higher its authority.

Why specific beats general

In almost every human system, a note about one person beats a rule about everyone. The manager’s written permission for one employee beats the handbook. This makes debugging easier: you walk down from the top, and the first level that has an opinion about the person gives the answer.

The trap of forgotten identity overrides

An engineer may add an identity override to test something and forget it. Months later, that person sees an old answer and no segment change will fix it. Whenever a result looks impossible, check the identity level first.

flowchart TD
    Q["What should this person see?"] --> I{"Identity override exists?"}
    I -- Yes --> IA["Use the identity override"]
    I -- No --> S{"Any segment override matches, in priority order?"}
    S -- Yes --> SA["Use the first matching segment override"]
    S -- No --> D["Use the feature default"]
    

A feature can carry a value, and an override can give a group a different value. This is one of the most useful combinations in Flagsmith.

What a value adds

A value is a piece of data attached to a feature: a number, a short text, or a structured text. It lets the same feature control not only whether something appears but how it behaves. A message banner can carry its words as a value, a limit can carry its number, and a theme can carry its colour name.

Different values for different groups

With a segment override, the value can differ by group. Most users see a seven-day trial, partners see thirty days, and staff see ninety. The code stays the same; it reads the value and acts on it. This turns a single feature into a flexible, group-aware setting.

State and value together

Remember that the state and the value are two dials. An override can turn the state on and set a value, or leave the state alone and change only the value. Decide clearly which dial you mean to turn. A common surprise is a feature that is off for some group, but still carries a value; the app must know whether to ignore the value when the feature is off.

When a feature offers several variations, a segment override can pin a group to one of them.

What multivariate means

A multivariate feature offers several versions of a value, such as three button colours, and shares users among them by percentages. It is the basic tool for comparing options.

Pinning a group

A segment override can choose a particular variation for its members, so those people are no longer part of the random split. For example, reviewers always see variation B so they can check it, while everyone else is divided among A, B, and C.

Keeping the experiment honest

People pinned by an override did not have an equal chance of seeing each variation. If you include them in your analysis, your numbers will lean toward whatever you pinned them to. Exclude them or analyse them separately.

Sometimes the group you want is simply “some of everyone”. A segment with a percentage rule gives you exactly that.

A slice as a segment

A segment can include a percentage split condition, which selects a steady slice of users, such as ten percent. When you attach an override to that segment, the slice receives the special answer. Raising the percentage later widens the slice. This is the standard way to roll a feature out gradually.

Steady, not random on every visit

Flagsmith does not roll dice each time a person visits. As far as is publicly described, it derives a stable number from the identity, so the same person lands in the same place on every visit. A feature that flickered on and off for the same user would feel broken, so stability matters. Increasing the percentage should add people at the edge without removing those already inside.

Where the slice sits in the order

A percentage-based override is still just one override in the ordered list. If a broader override sits above it, the slice may never be reached for some people. Think about who each override captures before you place a percentage slice among them.

flowchart LR
    ID["Identity"] --> N["Steady number from 0 to 100"]
    N --> Q{"Below the chosen percentage?"}
    Q -- Yes --> IN["In the slice: override applies"]
    Q -- No --> OUT["Outside: later overrides or default"]
    

An override lives in one environment. That is both a safety net and a source of drift.

Same segment, separate arrangements

The definition of a segment is shared across the project, but each environment keeps its own overrides. Development can have an override for staff that Production does not, and Production can keep the feature off for everyone while Staging turns it on for testers.

The safety net

Because of this, you can experiment boldly in Development. A mistaken override there cannot touch a customer. The environment boundary is one of the most valuable safety features in the whole system.

The drift problem

The same independence means environments quietly become different. Someone adds an override in Staging and forgets Production. Months later, a test in Staging proves less than you hoped because the real environment has a different arrangement. Compare environments before any important launch.

Follow a single request from the moment a person opens the app to the moment the feature appears or stays hidden.

sequenceDiagram
    participant App
    participant FS as Flagsmith
    App->>FS: Identifier plus traits
    FS->>FS: Look for identity override
    FS->>FS: Test segments in override order
    FS->>FS: Pick first matching override
    FS->>FS: Fall back to default if none match
    FS-->>App: State and value for each feature
    

Why this order is worth memorising

Almost every question of the form “why did this person get that?” is answered by walking these steps. They turn a mystery into a short checklist.

In remote evaluation, Flagsmith’s servers do the thinking and the app simply receives the result.

How it works

The app sends the identifier and traits to Flagsmith’s API. The server tests the segments, applies the overrides in order, and returns the final feature states. The app never sees the rules or the other overrides; it sees only its own answers.

Benefits

The arrangement stays private. A change to an override takes effect on the next request, subject to any caching. The app stays small, because it needs no evaluation engine.

Costs

Every evaluation needs a network trip, which adds a small delay. If Flagsmith cannot be reached, the app needs a fallback. And the traffic grows with the number of identity requests.

In local evaluation, a server-side SDK downloads the arrangements and applies them itself.

How it works

The SDK downloads an environment document containing the features, the segments, and the overrides, and refreshes it on a timer. When your code asks about a user, the SDK walks the override list right there in your own process, with no network trip per question.

The attractions

Answers are very fast and continue to work for a while if Flagsmith becomes unreachable, using the last downloaded document. It is a good fit for busy back-end services.

The responsibilities

The SDK needs a server-side key that must be kept secret, because the document contains every override. Changes reach your service only at the next refresh. And since the SDK decides locally, your code usually passes the traits in with each question. Exactly how stored traits are handled differs between modes, so check your SDK documentation.

The kind of app you build changes how much you can trust the traits that feed your overrides.

Client-side apps

Web pages and mobile apps normally use remote evaluation with a client-side environment key. That key is public, because it sits in code anyone can inspect. The traits come from the user’s own device, so they are only as honest as the device.

Server-side apps

Back-end services use a secret key and can use either evaluation style. They usually know more about a user from trusted internal sources, so they are the best place to compute the facts that matter.

Mixed systems

Many products do both. The server works out trustworthy traits and either evaluates the overrides itself or passes only the result to the browser. This keeps sensitive decisions out of the user’s reach.

An override can change what thousands of people see, so many teams add guardrails around changing it.

Change requests

Some Flagsmith plans offer change requests, where a proposed change must be reviewed and approved by another person before it takes effect. This is the digital version of a second signature on an important cheque. Availability depends on your plan, so confirm in the documentation.

Scheduled changes

Some versions let you schedule a change for a future time. A launch can then happen at a planned moment, such as the start of a campaign, without someone clicking a button at midnight.

Feature versioning

Where feature versioning is available, you can see earlier versions of a feature’s configuration and compare them. This makes it far easier to see exactly what an override change did and to return to an earlier arrangement if needed.

The audit log

Whatever your plan, Flagsmith records who changed what and when. When something odd happens, checking the log for recent changes to the feature or its segments is nearly always the first useful step.

The simplest and most valuable override is the one that shows a feature to your own team before anyone else.

How it works

Keep the feature off by default in Production. Add an override for “Internal staff” that turns it on. Your employees now experience the new feature in the real environment with real data, while customers see nothing. Problems that no test environment could reveal often appear within hours.

Why it works so well

Staff are forgiving, motivated to report problems, and easy to talk to. They form the safest test audience you will ever have. The override is cheap to add and cheap to remove.

Moving on

Once staff are happy, widen the audience by adding more overrides below the first, or by changing the default. The staff override can stay as a permanent lens or be removed when the feature is complete.

Many teams use overrides to give paying customers extra capabilities. This works, with care.

The common approach

A segment such as “Enterprise plan” is built from a plan trait. A feature, such as advanced exports, is off by default and on for that segment. When a customer upgrades, their trait changes and the feature appears without any release.

Where it can go wrong

Feature flags are made for controlling rollout, not for being the official record of what customers paid for. If the billing system says one thing and an override says another, someone gets the wrong features. Treat the billing system as the source of truth, and send the plan as a trait that the segment merely reads.

Enforce on the server

If a feature really must be restricted, the real check must happen on the server, not only in the screen. A flag decides what is displayed. The server must refuse the underlying action.

Laws, languages, and customs differ from place to place, and overrides let one product respect that.

Typical uses

A cookie notice may be required in some regions and not others. A payment method may exist only in certain countries. A new service may be allowed in one market and not yet in another. A country trait, a segment per region, and an override per feature handle all of these without separate versions of the app.

The reliability of location

Location can come from a profile, a billing address, a language setting, or a guess from the network address. Each has errors. A traveller, a person using a privacy tool, or an address that was never updated can all be misplaced. For legal matters, use the most reliable source and enforce the real rule on the server.

Write the reason down

When an override exists for a legal reason, say so in the segment description or the feature description. A future engineer should know whether the arrangement can be changed freely or needs a lawyer’s opinion first.

Mobile apps can run old versions for years. An override can keep new features away from apps that cannot display them.

The problem

A web page updates when you reload it. A mobile app does not. Some people never update. If a new feature needs new code, switching it on for an old app can produce a blank screen or a crash.

The version guard

The app sends its version as a trait. A segment such as “App version at least 6.2.0” exists. The feature’s override turns the feature on for that segment only, so old apps never receive it. Version comparison operators understand that 6.10.0 is newer than 6.9.0, which plain text comparison would get wrong. Check which version operator your Flagsmith offers.

A gentle sunset

A second override can show an “Please update” message only to apps below a chosen version. Combined with a value that holds the message text, you can change the wording without a release.

Some people should never be part of a rollout or an experiment. A high-priority override keeps them out.

Why exclusions matter

A very important customer should not be surprised by an experimental feature. Test accounts and automated checks should not distort your numbers. Both groups need protection, but for different reasons.

The exclusion override

Create a segment for the people to protect, then add an override at the top of the list that gives them the safe answer, usually the feature off, or the old variation. Because the first match wins, nothing below can change their experience.

Keep the group small and owned

A protection list that grows without limit becomes a way of avoiding every change. Give it an owner, review it regularly, and remove accounts that no longer need protection.

A careful rollout is mostly a story of overrides added and widened in a thoughtful order.

flowchart TD
    A["Feature off for everyone"] --> B["Identity overrides for a few named people"]
    B --> C["Override for internal staff"]
    C --> D["Override for beta testers"]
    D --> E["Override for a 5 percent slice"]
    E --> F["Override for a 25 percent slice"]
    F --> G["Default changed to on for everyone"]
    G --> H["Overrides and flag removed from code"]
    

What to watch on each rung

At every step, check the numbers that tell you whether things are fine: errors, slow responses, support messages, and whatever measure the feature was meant to improve. Wait long enough to see a real pattern before widening the audience. A step that looks quiet for ten minutes may hide a problem that appears the next morning.

The stop button

Before the first rung, decide what you will do if a measure turns bad and who will do it. The simplest stop is to switch the feature off at the top level, or to remove the widest override. Since the feature is separate from the deployment, either action takes seconds.

Finishing the story

When the feature reaches everyone and remains stable, change the default, delete the overrides, and remove the flag from the code. A ladder that stays standing forever is clutter.

Overrides decide who takes part in an experiment and who is kept out, which makes the results trustworthy.

Choosing the audience

An experiment on a sign-up page should include only people who are signing up. An experiment on a premium feature should include only premium customers. A segment narrows the audience to those who can actually give you an answer, so your numbers are not watered down by people who were never affected.

Keeping the groups comparable

For a fair comparison, the two groups must be alike in every way except the change. A percentage split inside one segment achieves this well, since both halves come from the same pool. Comparing one region with another mixes the effect of your change with the differences between regions.

Do not change the audience mid-way

Altering the overrides while an experiment runs makes the results hard to trust. Decide the audience in advance, record it, and hold it steady until the experiment ends.

An override is born for a reason and should die when the reason ends. Seeing the whole life helps you manage it.

The forgotten ending

Teams are good at beginnings and poor at endings. A finished rollout leaves behind overrides that quietly hold a few people on old behaviour, or that sit in the order and surprise the next person. Every override should have an owner and a reason to exist, and when the reason is gone, the override should go with it.

Retiring safely

Before deleting an override, ask who it affects now and what they will receive afterwards. If the default will give them the same answer, the removal changes nothing. If not, make the default carry that answer first. Remove one at a time and watch the result.

An override you have not tested is only a hope.

Test inside, outside, and the edges

For each override, check someone who is clearly inside the segment, someone clearly outside, and the strange cases: a missing trait, an empty value, capital letters, extra spaces, a number sent as text. Edge cases are where arrangements break.

Test the overlaps

Because the order matters, test people who belong to two or more segments with overrides on the same feature. Check that the one you expect wins. This is the test most often skipped and most often needed.

Look at one person in the dashboard

The Flagsmith dashboard lets you view an identity, its traits, and how its features evaluate. This is the fastest way to answer “why did this person get that?”. The exact layout depends on your version.

Keep a permanent test set

Create a small group of fake identities in Development: staff, a beta user, a premium customer, a user on an old app, a user with missing traits. After every change to an override or segment, look at that set. It is a tiny investment that catches most mistakes.

Automated tests

In your application tests, use an offline stand-in for Flagsmith that returns fixed answers, so tests run quickly and do not depend on the network. Separately, run a few checks against a real non-production environment to confirm that arrangements behave as expected.

A few overrides cost almost nothing. Many complicated ones add up.

The cost of walking the list

For each evaluation, the system walks the ordered overrides and tests segment rules until one matches. A handful of simple overrides is trivial. Dozens of overrides on dozens of features, each referring to a segment with many conditions, cost more, and in local evaluation you pay that cost inside your own service on every request.

Keep rules simple

Simple equality and number comparisons are quick. Complicated text pattern matching is slower. Prefer simple operators when they express your intent.

Mind the size of the document

With local evaluation, every segment and override lands in the document your servers download. A bloated document takes longer to fetch and uses more memory. Remove what you no longer use.

Ask once, reuse the answer

Request the features you need once per request or session and reuse the answer, instead of asking again at every line of code. In remote mode, avoid sending a fresh identity request for every click when a cached answer is good enough.

A good design assumes that any network service will occasionally fail.

What the app does without an answer

If the app cannot get an answer, it must still behave sensibly. Every flag in your code should have a safe default in code, usually the conservative choice. This applies to override-driven behaviour too, because a person who cannot be evaluated simply receives the default.

Caching helps

Many SDKs remember the last good answer. Local evaluation keeps the last downloaded document. Client-side apps can store the last response on the device. These measures reduce the damage from short outages, though they may serve slightly old answers.

Consider the worst outcome

Suppose overrides fail and everyone falls to the default. If the default is “feature off”, the worst case is that fewer people see something new. If a default is “premium feature on”, the worst case is that free users briefly see paid features. Choose defaults with this in mind.

flowchart TD
    A["Need a feature answer"] --> B{"Can we reach Flagsmith or a fresh copy?"}
    B -- Yes --> C["Apply overrides normally"]
    B -- No --> D{"Do we have a cached copy?"}
    D -- Yes --> E["Use the cached answer and log a warning"]
    D -- No --> F["Use the safe default in code and alert the team"]
    

An override change does not always reach every user in the same instant.

Where the delay hides

A server using local evaluation holds the old document until its next refresh. A browser or phone may have cached the last response. A delivery layer between you and Flagsmith may hold its own copy for a short time. Each layer is sensible alone, but together they decide how fast a change spreads.

Trait delay is separate

If a user upgrades to premium but the app only sends the trait at the next login, the segment will not recognise them until then. The override is correct; the trait is old.

Plan for it

Know how long each layer can delay a change and tell the people who depend on it. If you switch something off in an emergency, a few users may continue to see it for a short while. For truly urgent switches, test how quickly they take effect before the day you need them.

An override makes decisions from facts. If someone can lie about the facts, they can steer the decision.

Client-side traits can be faked

When a browser or phone sends its own traits, the user can change them. Someone using the browser’s developer tools can set “plan” to “premium” and ask for the features of that group. If the only protection for a feature is an override on a segment fed by self-reported traits, that protection is weak.

Compute important traits on the server

For anything that matters, have your trusted back end determine the trait from your own database, then either evaluate on the server or pass only the result to the client. The user then cannot change the fact that the decision is built upon.

Do not hide secrets in values

A value attached to an override is not a secret. Anyone who is allowed to receive it, and anyone who can read the client-side response, can see it. Never place passwords, private keys, or confidential data in a flag value.

Protect the keys

Client-side keys are public by design. Server-side keys can read the full environment document in local evaluation, including all overrides, so they must live in a secrets manager and never reach a browser or phone. Administration credentials, which can change overrides, deserve the strongest protection of all.

Overrides depend on segments, and segments depend on facts about people. Those facts deserve respect.

Collect the minimum

Send only the traits you need. If a decision can be made from a country, do not send a full address. If it can be made from a plan, do not send a payment history.

Prefer non-personal identifiers

Instead of an email address, many teams use an internal user number that means nothing to outsiders. If data ever leaks or is exported, it is far less revealing.

Understand what is stored

Flagsmith may store traits against identities. Treat that information as personal data. Know where it is kept, how long it stays, and how a person’s data can be removed on request. Your organisation’s privacy rules and the laws of the regions you serve should guide your choices.

Avoid sensitive categories

Do not build segments, and therefore overrides, on sensitive personal characteristics unless there is a clear, lawful reason and proper approval. Being able to target a group does not mean you should.

An override edit can change what thousands of people see. That deserves clear responsibility.

Roles and permissions

Flagsmith lets you control who can view features, edit them in each environment, and manage segments. The fine detail of roles, and which plans offer them, can differ, so check the current documentation. The general principle is to give the widest access in Development and the narrowest in Production.

Separate segment edits from override edits

Editing a segment’s rules changes who is in the group everywhere it is used. Editing an override changes what one feature does for that group in one environment. They have different blast radii, so consider giving them different permissions.

Approvals for risky changes

For sensitive Production overrides, a second pair of eyes catches mistakes. Where your plan offers change requests or scheduled changes, use them for the changes that matter.

Ownership

Every override should have an owner who can explain it. Overrides whose creator left the team long ago are a hidden risk, because nobody dares to touch them and nobody remembers why they exist.

You cannot manage what you cannot see. Make the effects of overrides visible.

Record what people saw

When an important decision depends on an override, log the feature, the result, and, where appropriate, which segment decided it. Without this, support staff and analysts must guess. Keep the logs free of personal details beyond what is needed.

Mark changes on your graphs

The audit log and webhooks can announce when an override changes. Put those markers on your monitoring graphs, so that when a line bends you can see whether a change happened at that moment.

Compare groups

For each rollout, choose two or three guardrail measures, such as error rate, response time, or cancellations, and watch them by group: people who received the override against everyone else. If the measure worsens for the group alone, the override is the suspect.

Watch for size changes

A segment that suddenly grows or shrinks is a signal. If “Premium customers” doubles overnight, either business is wonderful or a trait is being sent wrongly.

Everything you can do in the dashboard can usually be done by a program too.

Why automate

Clicking is fine for a handful of overrides. For dozens of environments, or when teams want their arrangements reviewed like other configuration, automation is better. Flagsmith provides an administration interface for creating and updating features, segments, and overrides. It uses a more powerful credential than the one used for evaluating features.

Overrides as reviewed configuration

Some teams keep a description of their overrides in a repository, review changes like any other, and apply them with a small tool. This gives history, review, and the ability to rebuild an environment. Make sure the tool never deletes or rewrites overrides that someone created by hand without noticing, since an unexpected change could alter what people see.

Keep evaluation and administration apart

Asking “what should this person see?” and “change this override” use different interfaces and keys. A service that only evaluates should never hold an administration credential.

These are tried and tested ways to use overrides well.

These habits look harmless at first and become painful later.

If you remember only a handful of habits, make them these.

Common mistakes behind these habits

Almost every mistake with overrides comes from skipping one of the habits above. Teams forget that overrides have an order, so the wrong answer wins. They trust a browser trait, so a feature leaks. They never retire an override, so the list fills with arrangements nobody understands. The habits are not complicated; they only need to be done every time.

The best way to learn ordering is to work through a few small puzzles. Each one uses the same decision ladder.

Puzzle one: the staff member in Canada

The feature “new-search” has two overrides. The first is “Canada”, which sets the feature off while a legal review is pending. The second is “Internal staff”, which sets it on. The default is off. Priya works for the company and lives in Canada. She matches both segments, so the first one wins and she sees the feature off. If the team wants staff to test it anyway, the staff override must move above the Canada override. The puzzle shows that the order is a decision, not an accident.

Puzzle two: the personal exception

The same feature now has an identity override for Priya that sets the feature on. Where does she land? The identity override sits above all segment overrides, so she sees the feature on, whatever the order below. This is why identity overrides are powerful for debugging: they cut through all other arrangements for one person.

Puzzle three: no match at all

Sam is a customer in Brazil on a free plan. He is not in any segment named by the feature’s overrides, and he has no identity override. He receives the feature default, which is off. Nothing went wrong; he simply fell through the ladder to the bottom.

Puzzle four: the right segment, the wrong order

A pilot team creates an override for “Pilot customers” that gives a longer trial value. Somebody had already placed “All paying customers” above it with a shorter trial value. Pilot customers are paying customers, so they match the broader segment first and never see the longer trial. The fix is to move the pilot override above the broad one.

A method that never fails

For any person and feature, ask in order: is there an identity override? If not, go down the segment overrides from the top and stop at the first match. If none match, use the default. Say the answer aloud with the reason, such as “off, because the Canada override matched first”. If you can say the reason, you understand the arrangement.

Here are some stories that show overrides at work in ordinary companies.

Let us follow one team through a complete override-based rollout.

A travel booking company wants to launch a “flexible dates” search. It changes the main search page, so the team plans carefully.

Step 1: Agree on the facts

The team lists the traits it needs: country, platform, app version, whether the user joined the beta programme, and whether the account is internal. They write the names, types, and allowed values in a shared document, and the back end begins sending them from the company’s own records.

Step 2: Create the feature and segments

They create the feature “flexible-dates-search”, off by default in every environment, with a description that names the owner and the plan. They create the segments “Internal staff”, “Beta programme”, “Mobile 6.2 or newer”, and “Affected device types”. Each has a clear description.

Step 3: Build the overrides in Development

In Development, the team adds overrides in this order: “Affected device types” off, “Mobile 6.2 or newer” gate, “Internal staff” on, “Beta programme” on. They realise the version gate cannot be a simple override because it must combine with the audience. They fix this by adding the version condition to the audience segments themselves, and test their fake identities, including a staff member on an old app, who correctly sees nothing.

Step 4: Repeat in Staging and Production

They recreate the overrides in Staging, test again, and then in Production, where the default stays off. Before the launch, a colleague compares the lists in the three environments line by line.

Step 5: Roll out in steps

Day one: staff only. Day three: beta members. Day six: a five percent slice of eligible mobile users. Day ten: twenty-five percent. At each step, they watch search errors, response time, and completed bookings, comparing members with everyone else.

Step 6: A bump

At twenty-five percent, searches slow a little. The team lowers the slice to five percent, finds a slow database query, fixes it, and widens again. Because the problem appeared while only a quarter of users were affected, most customers never noticed.

Step 7: Finish

When the feature has reached everyone and stayed steady for two weeks, the team changes the default to on, removes the overrides, deletes the flag from the code, and archives it. The permanent segments, such as “Internal staff”, remain for the next project.

flowchart LR
    A["Agree traits"] --> B["Create feature and segments"]
    B --> C["Build overrides in Development"]
    C --> D["Repeat in Staging and Production"]
    D --> E["Staff, then beta, then 5 percent"]
    E --> F["25 percent"]
    F --> G{"Healthy?"}
    G -- No --> H["Lower the slice and fix"]
    H --> E
    G -- Yes --> I["Default on, remove overrides and flag"]
    

Overrides are powerful, and like every power tool they have costs.

The central trade-off

Each override buys flexibility at the price of one more thing to understand. The skill is to add overrides that answer real needs and remove them when the needs are gone. A few clear overrides beat a large number of clever ones.

When a result surprises you, work through the evaluation steps in order. Most puzzles have simple causes.

A calm routine

First, view the identity and read its traits. Second, check for an identity override. Third, read the segment overrides from the top and find the first match. Fourth, check the default and the environment. Fifth, read the audit log for recent edits. Write down what you find, because the same puzzle often returns.

Many teams begin with targeting rules buried in code. Moving them into overrides is a calm, step-by-step job.

Find the hidden rules

Search your code for places where behaviour depends on who the user is: checks for staff emails, plan names, countries, or version numbers. List each one with what it does, who owns it, and how often it changes.

Define clean traits and segments

Make sure the information each rule uses is sent as a clean, agreed trait. Build segments that select the same people as the old code, and name them for their meaning.

Create matching overrides and compare

Create the feature, with a default that matches today’s behaviour for everyone else, and add overrides that match the old rules. For a period, let the old code decide, but log when the override would have disagreed. When the two agree for long enough, switch the code to rely on Flagsmith.

Remove the old rule

Delete the hard-coded check so there is only one source of truth. Leaving both behind is a recipe for confusion when they drift apart.

flowchart LR
    A["Find hidden rules in code"] --> B["Define clean traits and segments"]
    B --> C["Create feature, default, and overrides"]
    C --> D["Run both and log differences"]
    D --> E["Switch to Flagsmith"]
    E --> F["Delete old rules"]
    

Tools help, but habits keep overrides healthy over years. A light process is enough.

Before adding an override

Look at the feature’s current list first. A suitable override may already exist, and adding a second one may change the order for people already covered. State in one sentence who the override is for and why.

Before changing an existing one

Find out who is affected. Tell the owner of the feature and the owner of the segment. Make the change in Development first, test with the permanent fake identities, and apply it to Production at a quiet time.

During a rollout

Announce the plan in the team chat: which overrides, in which order, with which measures to watch. Name the person who can stop the rollout. Record each step so that anyone can see where things stand.

After a rollout

Remove what is finished: the overrides, the temporary segments, and the flag in the code. Add a short note to your team’s record describing what was learned. Review the whole set of features every few months and ask of each override, “Who is this for, and do we still need it?”

Walk through these questions before relying on overrides for something important.

How to use the list

Hold a short review before your first important override goes live, and again whenever your use grows. Ask for real answers, not hopes. Any row where the team hesitates is a place where something will eventually go wrong. Write down the gap, give it an owner, and fix the most dangerous one first.

Real products rarely have one feature on its own. Features lean on each other, and their overrides must agree.

Features that belong together

A new reporting area may need a feature for the page, another for the export button, and a third for a new data source. If staff see the page but the data source override was forgotten, the page opens empty. Overrides on related features should be planned as a set, with the same audience and a similar order.

Use the same segments for related features

When related features share the same segments, widening the audience is simple: you add the same step to each. When each feature uses a slightly different segment, the audiences drift apart, and some people receive half of a product. Reuse is a quiet kind of safety.

Mind the direction of dependence

If feature B only makes sense when feature A is on, then no person should ever receive B without A. Write that rule in the descriptions, and when you test, check that the people at the edges of each segment receive a consistent pair. Your application code should also check the dependency and ignore B when A is off.

Roll forward and roll back together

When something goes wrong, you will want to switch the whole set off at once. Keep a short note listing which features belong to the launch, so that an on-call engineer is not hunting through the dashboard at night.

flowchart TD
    SEG["Shared segment: Beta programme"] --> A["Feature A: page"]
    SEG --> B["Feature B: export button"]
    SEG --> C["Feature C: new data source"]
    A --> OK{"All three on for the same people?"}
    B --> OK
    C --> OK
    OK -- Yes --> GOOD["Consistent experience"]
    OK -- No --> BAD["Half a product: investigate"]
    

The dashboard shows the current state, but it does not explain your intentions. A short written map does.

What belongs in the map

For each important feature, write down the default, the list of overrides in order, the reason for each, the owner, and the planned end date. Add a line about related features and about anything that must never change without a conversation, such as a legal restriction.

Where to keep it

Keep the map where your team already looks: the feature description, a page in your team wiki, or a file in the repository. The best place is the one that is updated as part of the normal change process, not a document that is written once and forgotten.

Why it pays off

When a new engineer joins, the map answers their first ten questions. When an incident happens, it tells the on-call person what each override was meant to do. When an auditor asks why a group received a feature, the answer is already written. The effort is small and the benefit grows with every month.

Keeping it honest

A stale map is worse than none, because people trust it. Review the map during the regular override review, compare it with the dashboard, and fix any difference at once.

A quick reference for every important word in this guide.

Short answers to the questions beginners ask most often.

Segment overrides are how a group of users receives its own answer for a feature.

Every feature has a default answer in each environment. A segment override attaches a special answer, a state and a value, to the members of one segment for one feature in one environment. When a person belongs to several segments, the overrides are tried in priority order and the first match wins. An identity override outranks all segment overrides, and the default catches everyone else.

Because the order is part of the meaning, place exclusions first and narrow segments above broad ones. Keep the default conservative, test the overlaps, compare environments before launches, and remember that remote evaluation keeps arrangements on Flagsmith’s servers while local evaluation brings them into your own service. Treat client-side traits as claims that can be faked, enforce real permissions on the server, collect the minimum personal data, and retire overrides when their work is done.