Before learning any Flagsmith words, let us feel the problem. Rules for groups are powerful, but real life keeps producing people who do not fit the groups.

Groups are not enough

A feature flag is a switch that turns a behaviour on or off without a new release. At the simplest level it has two positions for everyone. A smarter system lets you decide by group: “on for staff,” “on for premium customers,” “on for ten percent.” These group rules cover the great majority of decisions. But think about the daily life of a product team and you will meet a different kind of request, again and again.

The cost of building a group for each exception

You could answer every one of these requests by inventing a trait and a segment. For the eager beta customer you would add a trait called “early_access,” send it from your application, build a segment that reads it, and attach the segment to the feature. That is the right answer when ten or a hundred people need the same exception. But for a single person, with a single feature, for a single week, it is heavy. You change application code, send new data about a person, and create a permanent object in your project that will confuse people next year.

An identity override is the light answer. You open that one person in the dashboard, pick the feature, and choose the answer they should get. No application change, no new trait, no new segment. The exception exists in one clearly visible place, attached to the person it concerns.

A short story

Rohan leads support at a company that sells accounting software. On Monday a large customer, “Sunrise Traders,” writes that the new invoice screen hides a button their staff use hundreds of times a day. Engineers need three days to fix it. Rohan does not wait. He opens the Sunrise Traders identity in the live environment, finds the feature “new invoice screen,” and creates an override that switches it off for that identity alone. Within minutes, Sunrise Traders sees the old screen again. Every other customer keeps the new one. On Thursday the fix ships, Rohan deletes the override, and the customer joins everyone else. The whole episode touched no code and no other customer.

Three kinds of exception, three different needs

Not every exception is the same, and noticing the kind helps you choose the right tool. A privilege exception gives a person more than the rule allows: early access, a higher limit, a premium feature during a trial. A protection exception gives a person less than the rule allows, to shield them from harm or from change: a disabled feature for a client in a freeze. A diagnostic exception exists only so that someone can look at the product through another person’s eyes: a support engineer who reproduces a customer’s problem on a test identity.

Privilege exceptions carry the risk of giving away value by accident. Protection exceptions carry the risk of being forgotten and so denying a person a good thing for years. Diagnostic exceptions carry the risk of leaking real customer details into test accounts. All three are legitimate, and all three benefit from the same simple habits: a reason, an owner, and an end date.

An override touches several parts of Flagsmith at once. A quick map of those parts makes everything else easy to follow.

The map of Flagsmith

Flagsmith arranges things like a set of boxes inside boxes. An organisation is the company account. Inside it live projects, usually one per product. Inside a project live features, which are the switches and settings, and segments, which are saved groups of people defined by rules. A project also holds environments such as Development, Staging, and Production, so that the same features can be tried safely before they reach real customers.

flowchart TB
    ORG["Organisation: the company account"] --> PRJ["Project: one product"]
    PRJ --> FEAT["Features: shared definitions"]
    PRJ --> SEG["Segments: shared group rules"]
    PRJ --> ENV1["Environment: Development"]
    PRJ --> ENV2["Environment: Staging"]
    PRJ --> ENV3["Environment: Production"]
    ENV3 --> ID1["Identity: customer 1001"]
    ENV3 --> ID2["Identity: customer 1002"]
    ID1 --> OV1["Override: new invoice screen is off"]
    ENV2 --> ID3["Identity: tester A"]
    ID3 --> OV2["Override: new invoice screen is on"]
    

Four words you must know

The simplest definition of an identity override

An identity override is a feature state that belongs to one specific identity, for one specific feature, in one specific environment. It says: “For this person, in this environment, ignore all the group rules and the defaults for this feature, and give this answer instead.” It can set the enabled position, and, for features that carry a value, it can set the value as well.

Why the layers are designed this way

It is worth asking why Flagsmith places the personal override above everything else. The answer is predictability. When a human takes the trouble to say “this person gets this answer,” the human expects that answer to hold. If a segment could quietly overrule a personal decision, every exception would be unreliable, and support teams could never promise anything to a customer. By making the personal layer the strongest, Flagsmith lets an exception mean exactly what it says. The cost, as we will see, is that a forgotten exception keeps meaning what it says for as long as it exists.

Every time an application asks for a feature, Flagsmith works through layers from the most specific to the most general. The first layer with something to say wins. The identity override is the most specific layer of all.

The layers

flowchart TB
    START["Request: environment key and identifier"] --> L1{"Layer 1: is there an identity override for this feature?"}
    L1 -- Yes --> R1["Answer comes from the identity override"]
    L1 -- No --> L2{"Layer 2: does the identity match a segment that overrides this feature?"}
    L2 -- Yes --> P["If several match, choose the highest priority"]
    P --> R2["Answer comes from that segment override"]
    L2 -- No --> L3{"Layer 3: is the feature multivariate or a percentage split?"}
    L3 -- Yes --> H["Stable hash chooses a variation"]
    H --> R3["Answer comes from the chosen variation"]
    L3 -- No --> R4["Layer 4: the environment default state"]
    

Look at the diagram slowly. For one feature, Flagsmith first asks whether this exact identity has a personal override. If it does, the question is closed, and no segment is even consulted. If it does not, the segments are tested against the person’s traits. If none matches, a variation or percentage rule may decide. Only if all of that is silent is the environment default used.

What “wins” means in practice

The override beats segments even when the person matches a segment that would give the opposite answer. If a segment says “enable the new design for all premium customers” and one premium customer has an override saying “disabled,” that customer sees the old design. The override also beats the percentage rollout. A person who falls inside the ten percent still sees the feature disabled if they carry a disabled override. And it beats the default.

The override is per feature

An override applies to one feature at a time. If you want a person to receive special answers for three features, you create three overrides. Their answers for every other feature continue to come from segments and defaults as usual. This keeps an exception narrow: you change exactly what you intended.

Reading the identity page as a story

The identity page is not just a list. It tells a short story for every feature, and learning to read that story makes you quick. For each feature the page shows the answer the person receives, and where it came from. If the source is an identity override, the story is “a human decided this for this person.” If the source is a segment, the story is “this person’s traits matched a rule.” If the source is the default, the story is “nothing special applies.” When the story does not match your expectation, the mismatch itself is the clue. A person who should be in a segment but shows the default has a trait problem. A person who is in a segment but shows a different answer has a stronger layer above it, and the strongest layer is the personal override.

Practise this reading on three or four identities in a quiet moment, before any emergency. Pick a feature, predict the layer that will win, then open the page and check. After a few rounds you will find the answer in your head before the page loads, and your confidence in the system will grow with it.

You cannot override a person Flagsmith has never heard of. This chapter explains how identities are created, so you know when an override is possible.

The environment key and the SDK

Your application talks to Flagsmith through an SDK, which stands for software development kit. It is a small library, written for your programming language, that handles the conversation. When the SDK starts, it is given the environment key, a code that tells Flagsmith which environment the application belongs to. Production applications carry the Production key, staging applications carry the Staging key, and so on.

Three ways an identity appears

Why this matters for overrides

Because identities can be created in advance, you can set an override before the person first arrives. A product manager can create the identity for a customer who is joining next week, attach the early access override, and the first time that customer opens the application the correct feature state is already waiting. This is useful for planned beta programmes and demos.

sequenceDiagram
    participant PM as Product manager
    participant D as Flagsmith dashboard
    participant FS as Flagsmith
    participant APP as Application
    participant U as Customer
    PM->>D: Create identity customer-884 in Production
    PM->>D: Add override: new reports is on
    D->>FS: Save identity and override
    U->>APP: Opens the app for the first time
    APP->>FS: Get flags for customer-884 with environment key
    FS->>FS: Find identity, find override, work out answers
    FS-->>APP: new reports is on, others from segments and defaults
    APP-->>U: Shows the new reports screen
    

The identifier must match exactly

An override is attached to the identifier text. “customer-884” and “Customer-884” are different identifiers to a computer, and so are “customer-884” and “customer-884 ” with a space at the end. If the identifier your application sends differs by even one character from the one in the dashboard, the person will not find their override. Copy identifiers from your own database or from the identity search in the dashboard, never retype them from memory.

Like any record, an override has a life: it is created, read, changed, and removed. Knowing each action tells you where mistakes can enter.

Creating an override in the dashboard

In the Flagsmith dashboard, you choose the project and the environment, and open the identities area. You search for the identity by its identifier, or add it if it does not exist yet. On the identity’s page you see its traits and the list of features with the state each one currently gives that person. For a feature you want to change, you pick the action that overrides it for this identity, choose enabled or disabled, set a value if the feature carries one, and save. From that moment, the person’s answer for that feature comes from the override.

Other ways to manage overrides

The dashboard is the friendliest door, but it is not the only one. Flagsmith offers an Admin API, which is a set of web addresses that programs can call to read and change things. A script can create identities and overrides in bulk, for example for a list of two hundred beta customers. Teams that manage infrastructure as code may also use a Terraform provider, where the desired overrides are written in files and applied automatically. Which of these is available, and how exactly it is named, depends on your Flagsmith version, so confirm in the documentation.

Changing and removing

To change an override, you edit it on the same identity page, for instance flipping enabled to disabled or editing the value. To remove it, you delete the override. Once removed, the person falls back to the next layer: segments, then the default. Removing is the step teams most often forget, which is why a later chapter is devoted to it.

What a good request looks like

The quality of an override often depends on the quality of the request that led to it. A vague request such as “please give this customer the new thing” produces vague, forgotten overrides. A good request answers six questions. Which person, by exact identifier? Which feature, by exact name? Which environment? Which direction, enable or disable, and with which value if any? Why, in one sentence? Until when? A team that insists on these six answers, even in a hurry, produces overrides that can be understood a year later.

Make the request form easy. A short template in your ticket system with six boxes takes less than a minute to fill and removes most back-and-forth. For emergencies, allow the form to be filled afterwards, within a day, so help is never delayed, but make the later filling a firm rule. Emergencies are exactly when people forget to write things down.

Verifying with the person

After you create an override, the story is not finished until the person has seen the effect. Ask them to refresh, sign out and in, or restart the application, and to confirm. Customers appreciate being told what to expect: “In a few minutes, your invoice screen will return to the older layout. Please sign out and in once if it does not.” This small message turns a technical change into good service, and it gives you evidence that the override reached the real screen.

An override is a small bundle of answers. Understanding what is inside lets you decide exactly how much to change.

The enabled position

Every feature has an enabled position: on or off. An override can set this to either. “Enabled” means the feature is on for the person, “disabled” means it is off. Note that an override can switch a feature off for someone even when everyone else has it on. This is how you protect a customer from a risky launch.

The value

Besides the on or off position, a feature may carry a value: a number, a piece of text, or a small structured text. Teams use values as remote configuration, meaning settings that live in Flagsmith instead of in the application. Examples are the maximum number of items on a page, the colour of a button, or the address of a help page. An identity override can change the value just for one person, so a beta customer can receive “twenty items per page” while others see “ten.”

Multivariate features and overrides

A multivariate feature has several variations with weights, such as forty percent for blue, forty percent for green, and twenty percent for the control. Normally a hash chooses a variation for each person. An identity override can pin one person to one variation. This is helpful in two situations. First, to let a team member or a demo account always see a particular variation. Second, to remove a complaining person from an experiment while keeping everyone else in it.

What an override cannot do

• It cannot create a feature. The feature must already exist in the project.
• It cannot change the feature’s definition. Name, type, and tags belong to the feature, not to the identity.
• It cannot affect another environment. It lives only where it was made.
• It cannot change traits. Traits and overrides are separate records on the identity.
• It cannot apply to a group. One identity, one override per feature. Groups belong to segments.

Three tools can change what a person sees. Choosing the right one is the most important skill in this guide.

The three tools side by side

The visibility problem

The biggest difference is visibility. A segment override is visible on the feature screen: anyone who opens the feature sees which segments override it. An identity override is visible only on the identity’s own page. A person who studies the feature screen will never see it. So a feature can look perfectly tidy while a hundred hidden personal exceptions change what a hundred people receive. This is why teams keep identity overrides rare, recorded, and reviewed.

A decision path

flowchart TB
    NEED["A person needs a different answer"] --> Q1{"Will more than a few people need the same exception?"}
    Q1 -- Yes --> SEGPATH["Create a trait and a segment, use a segment override"]
    Q1 -- No --> Q2{"Is it temporary, with a clear end date?"}
    Q2 -- No --> Q3{"Is there a lasting reason that could be a trait?"}
    Q3 -- Yes --> SEGPATH
    Q3 -- No --> OVR["Use an identity override, record the reason"]
    Q2 -- Yes --> OVR
    OVR --> END["Set a reminder to remove it"]
    

When one-off becomes a group

The clearest signal that you should leave overrides behind is repetition. The first time a beta customer asks for early access, an override is perfect. The fifth time, you are quietly building a group by hand. Stop, define a trait such as “beta_tester,” send it from your application or set it through the API, create a segment that reads it, and attach the segment to the feature. Then delete the five overrides. The group is now visible on the feature screen, easy to extend, and easy to measure.

A worked comparison

Let us follow one feature, “new dashboard,” through all three tools. The environment default is off. A segment named “Premium customers” overrides it to on. Customer A is a premium customer with no personal override. Customer B is a premium customer with a personal disabling override. Customer C is a free customer with a personal enabling override. Customer D is a free customer with nothing special.

• Customer A matches the segment, has no personal override, and so receives on, from the segment.
• Customer B matches the segment, but the personal override is stronger, so B receives off.
• Customer C matches no segment, but the personal override says on, so C receives on.
• Customer D matches nothing and has nothing personal, so D receives off, from the default.

Notice that the feature screen alone would tell you only about the default and the segment. A reader of that screen would predict on for A and off for everyone else, and would be wrong about B and C. This is the hidden-exception effect in a small, concrete form.

The same person can exist in Development, Staging, and Production, and in each place they are a different record. This design protects you, and it also catches people out.

What belongs to the project and what to the environment

Three consequences

flowchart LR
    subgraph STG["Staging environment"]
        S1["Identity: tester-1"] --> S2["Override: new screen on"]
    end
    subgraph PRD["Production environment"]
        P1["Identity: tester-1, a separate record"] --> P2["No override yet"]
    end
    S2 -. "does not travel" .-> P2
    

The wrong-environment accident

The most common override mistake is a simple one: creating the override in the wrong environment. An engineer wants to help a Production customer but has Staging open. The override is saved perfectly, the customer sees nothing, and everyone is confused. The reverse is worse: an engineer experimenting in what he thinks is Staging changes a real customer’s experience in Production. The cure is habit. Always read the environment name before saving, and consider colouring or naming environments so that Production is unmistakable.

Making environments hard to confuse

Teams reduce the wrong-environment accident with small, cheap habits. Name environments clearly and in capital letters for Production. Use different browser profiles, or different window colours, for Production and Staging administration. Require a second confirmation word before bulk changes in Production. And print the environment name at the top of every script output. None of these costs money, and each removes a class of errors that otherwise returns every few months.

It also helps to keep Production edits rare and deliberate, performed from a short written plan, while Staging edits can be casual. When the two feel different in daily work, people naturally slow down in the place that matters.

A healthy override is born with a reason, lives for a short, known time, and dies on schedule. An unhealthy one is born in a hurry and lives for years.

stateDiagram-v2
    [*] --> Requested: Someone asks for an exception
    Requested --> Approved: Owner agrees and sets end date
    Approved --> Active: Override created and verified
    Active --> Reviewed: Scheduled review
    Reviewed --> Active: Still needed, new end date
    Reviewed --> Retired: No longer needed
    Active --> Promoted: Many people need it, becomes a segment
    Promoted --> Retired: Overrides deleted
    Retired --> [*]
    

The stages in plain words

• Requested. A customer, tester, or colleague asks for an exception. A ticket records who, what, and why.
• Approved. Someone with authority agrees and fixes an end date. Without an end date the override has no natural death.
• Active. The override exists, was verified, and the people involved know it is there.
• Reviewed. On a schedule, such as every month, someone reads the list of active overrides and asks if each is still needed.
• Retired. The override is deleted and the person returns to normal rules.
• Promoted. If many people need the same exception, it becomes a trait and a segment, and the personal overrides are deleted.

Why end dates are everything

Almost every override problem is an end-date problem. An override with an end date is a loan. An override without one is a gift that nobody remembers giving. Two years later, a new engineer asks why a customer behaves differently, and nobody knows. Writing an end date, even a rough one, turns an invisible exception into a visible promise.

Who owns the override?

Every override needs a human owner, a person who can answer “is this still needed?” The owner is usually the requester or the product manager responsible for the feature, not the engineer who clicked the button. Engineers change jobs, and a button-clicker is a poor long-term owner. When the owner leaves the company or changes teams, the register must show who takes over, or the override is retired. This one rule turns a pile of mysteries into a list of responsibilities.

The monthly review in practice

A review need not be long. Open the register and the list of overrides side by side. For each row, ask three questions: is the end date reached, is the owner still the owner, and would this be better as a segment? Delete the expired ones on the spot, with a before and after read. Move repeated cases into a plan to create a segment. Update the review date for the rest. Twenty minutes a month keeps the whole system tidy. Teams that skip the review for a year often spend a week untangling the result.

Traits and overrides live on the same identity page, which makes people think they are connected. They are not. Understanding this prevents a whole family of confusions.

Traits are facts, overrides are decisions

A trait is a fact about a person, sent by your application, such as plan equals premium. A segment reads traits and decides group membership. An override is a decision made by a human, saved in Flagsmith, which says what to give this person. Traits flow from your system to Flagsmith. Overrides flow from a human to the person’s answer.

What changes when traits change

When a trait changes, segment membership is worked out again, so the person’s answer from segments can change at once. But the override does not change. Suppose a customer has an override that disables a feature, and later their plan trait changes to premium, which would put them into an enabling segment. They still see the feature disabled, because the override outranks the segment. This is correct behaviour, but it surprises people who expected the plan upgrade to “fix” the situation.

Using traits to avoid overrides

If you find yourself creating overrides repeatedly for people who share a reason, the reason is a trait waiting to be named. A support agent might override twenty accounts for “customers affected by the March billing issue.” A trait named “billing_issue_march” set through the API on those accounts, and a segment that reads it, would give one visible group instead of twenty hidden exceptions, and a single place to switch the group off.

The visible identity page

The identity page shows both: traits at the top, and the list of features with the answer each gives and where the answer came from. Learn to read it like a report: for each feature, which layer won, and does that match what you expected? Most puzzling cases are solved by this one page.

Overrides are not just a support trick. Skilled teams weave them into the way they launch, test, and protect features.

Workflow 1: the internal dark launch

A dark launch means deploying a feature to the live product but keeping it hidden. The code is in Production, the default is off, and a few named people see it through overrides. Product managers, designers, and testers explore the real thing on real infrastructure. When they are happy, the team moves to a segment such as “Employees,” then to a percentage rollout, and finally to everyone. Overrides are the first, smallest ring of this expanding circle.

Workflow 2: the design partner programme

Many companies work closely with a few customers who help shape new features. These design partners get early access and give feedback. Overrides are the quick way to include them. When the programme has five or ten partners, a trait and a segment become better, and the team converts the overrides at that point.

Workflow 3: the protected customer

Some customers cannot receive changes without notice: hospitals, banks, government offices. A policy might say “no new feature reaches these customers until their change board approves.” When a feature launches by percentage, a disabled override on each protected identity keeps them safe regardless of the dice. This works well for a handful of accounts. For dozens, a trait such as “change_freeze” and a segment is better, because the group will keep growing.

Workflow 4: the emergency exit for one customer

When a new feature harms one customer, the fastest relief is a disabled override for them. It buys engineers time without a rollback that would also take the feature from thousands of happy customers.

flowchart LR
    DARK["Ring 0: dark launch, a few overrides"] --> EMP["Ring 1: Employees segment"]
    EMP --> PART["Ring 2: Design partners segment"]
    PART --> PCT["Ring 3: Percentage rollout"]
    PCT --> ALL["Ring 4: Everyone, default on"]
    PROT["Protected customers: disabled overrides at every ring"] -.-> PCT
    HELP["Harmed customer: disabled override at any time"] -.-> ALL
    

Handing over from overrides to the next ring

The moment a feature graduates from the internal ring to a wider ring is the moment most overrides lose their purpose. Prepare the handover on paper. List the people who hold enabling overrides, and check that each of them will be covered by the next ring, for example the “Employees” segment. Only then switch the next ring on. If the person is covered, delete the override, because it is now redundant, and a redundant override is a future surprise. If the person is not covered, decide on purpose whether the exception should continue, and record the new reason and end date.

This tidy handover prevents a common confusion. Months later, someone removes the Employees segment from the feature, expecting staff to lose access, yet three staff still see it because of old personal overrides. The feature screen said one thing, and the people said another. A handover checklist closes that gap before it opens.

Clicking works for one person. When you need to handle fifty beta customers or clean up hundreds of old exceptions, automation is safer and faster.

The Admin API

An API is a set of web addresses that programs use to ask a service to do things. Flagsmith’s Admin API lets a program read and change projects, environments, features, segments, identities, and overrides. To use it, a program presents a secret API token that proves it has permission. Because it can change live behaviour, the token must be guarded like a password.

What automation is good at

Safe habits for scripts

Infrastructure as code

Some teams describe their Flagsmith setup in files, using a tool such as Terraform, and apply the files automatically. The benefit is review: every change is a proposed edit that others can read before it goes live. The cost is speed: an emergency override for one customer should not wait for a code review. Many teams keep long-lived settings in code, and allow a small, audited, manual path for emergency exceptions, with a rule that emergency overrides are removed or captured in code within a few days.

Reports worth building

Once you can read overrides through the Admin API, a handful of small reports pay for themselves quickly. The first lists every identity override in Production with its age, so the oldest can be questioned. The second counts overrides per feature, so you can spot a feature that has outgrown personal exceptions. The third compares the live list with the register and prints any override that is missing from the register, which are the undocumented ones. The fourth lists every enabling override on a feature marked as paid, so a finance or product owner can confirm each one is intended. Each report is simple, and together they turn a hidden layer into a visible one.

Send these reports to the owners, not only to engineers. A product manager who receives a weekly list of the exceptions on her features will remove them faster than any reminder from the platform team.

A tool this sharp needs rules about who may hold it. Governance is the small set of habits that keeps personal exceptions honest.

Permissions

Flagsmith can limit who may view, edit, or approve changes in each project and environment. Depending on your plan, you can create roles or teams with different rights, such as “may read everything,” “may change Staging,” or “may change Production.” Good practice is to let many people read, fewer people edit Staging, and only a small group edit Production. Because an identity override in Production changes a real customer’s experience at once, the right to create it deserves a careful grant.

Approval and change requests

Some plans offer change requests, where a proposed change to a feature state must be reviewed and approved by another person before it takes effect. If your plan includes this, check whether it covers identity overrides or only the environment and segment levels, because this has varied between versions. If identity overrides are outside the approval flow, you need a substitute: a ticket with an approver’s name, and a second person reading the identity page after the change.

The audit log

The audit log is Flagsmith’s record of who changed what and when. It is your memory when someone asks, “who gave this customer that exception?” Make a habit of recording the ticket number in any note field that your version offers, so the audit entry points to the reason.

The register

A simple shared register, a table in a wiki or spreadsheet, makes governance real. Each row lists the identifier or a safe reference to it, the feature, the environment, the direction (enable or disable), the requester, the approver, the reason, the created date, and the review date. Anyone who wonders about an exception can read the register before bothering an engineer. Review it monthly, and remove rows as overrides are deleted.

Separating duties

A useful governance idea is the separation of duties: the person who asks for an exception should not be the only person who approves and creates it. A product manager may request, a team lead may approve, and a release engineer may create. Even a small team can apply the idea by asking a colleague to read the ticket and the identity page before the override is saved. A second pair of eyes catches wrong environments, mistyped identifiers, and forgotten end dates, which are the three most common errors in this whole subject.

An override changes what a person can do and see. That makes it part of your security story, and the identifier it sits on makes it part of your privacy story.

The main risks

Flags are not locks

This point deserves its own heading. A feature flag decides what the application chooses to show. It does not by itself stop a determined user from calling the underlying service. If an override enables a paid report, the server that produces the report must also check that the customer is entitled to it, or that an authorised exception exists, using your own system of record. Think of the flag as the door sign and the server check as the lock.

Habits that reduce risk

• Use opaque identifiers. A random internal number reveals nothing if it leaks.
• Keep the secret key on servers. Browsers and apps use the public client key. Server keys and Admin API tokens never ship in code that users can download.
• Grant the least access. Give edit rights to those who need them and no one else.
• Review enabling overrides on paid features. They are the ones with money attached.
• Rotate tokens. Replace API tokens on a schedule and whenever a person with access leaves.
• Plan for deletion. Know how to remove one person from every environment, and from your register.
• Mind the register. If it contains personal information, protect it like any customer file.

flowchart TB
    OVR["Override enables a sensitive feature"] --> UI["Application shows the feature"]
    UI --> CALL["User action calls your server"]
    CALL --> CHK{"Server checks entitlement in your own system"}
    CHK -- Entitled or approved exception --> OK["Request allowed"]
    CHK -- Not entitled --> NO["Request refused, feature hidden or denied"]
    

Handling real customer data in test accounts

Diagnostic exceptions bring a special privacy risk. To reproduce a customer’s problem, support may copy that customer’s traits onto a test identity. If the traits contain personal data, the test identity now holds it, in an account that many staff can open. Copy only what the reproduction needs, such as plan, version, and country. Never copy names, emails, or free-text fields. Delete the test identity when the investigation ends, and record the deletion in the ticket. This habit keeps a helpful practice from becoming a quiet leak.

Insider misuse and mistakes

Most security failures with overrides are honest mistakes, not attacks. A well-meaning colleague enables a paid feature for a friendly customer without telling anyone. A tired engineer disables a safety feature for a complaining client. Strong governance protects against both: second-person review for enabling overrides on paid features, an announcement in a channel for every Production change, and a monthly look at the audit log. The goal is not to distrust people, but to make every exception visible so that mistakes are caught early and kindly.

An override is a promise about what one person will see. Like every promise, it deserves a check before and after it is made.

What to test

• The override itself. Does the person’s identity page show the override as the source of the answer?
• The application effect. Does the real screen change when the answer changes?
• The neighbours. Do other people with similar traits remain unaffected?
• The removal. After deleting the override, does the person return to the right segment or default answer?
• The identifier match. Does the application send exactly the identifier the override was created for?

A before-and-after checklist

Testing without hiding problems

Overrides make testing easy, and that is exactly the danger. A tester with an enabling override sees the feature working, but real customers depend on segments and percentages, which the tester never exercised. For release testing, create personas with the traits of real customer groups, and let them match segments. Use overrides only for the first, internal rehearsal, and for test accounts that need a fixed answer.

When someone says “my screen is different,” you need a calm method. For overrides, the method starts and ends on the identity page.

A debugging routine

What to measure

Alerts that help

Connect Flagsmith’s webhooks or audit log, where your version supports it, to a shared channel, so that every Production override creation appears as a short message. This makes exceptions public inside the team. Public exceptions get explained, questioned, and removed. Quiet exceptions grow old.

Keeping a short incident note

Whenever an override causes surprise, write a short note of five lines: what the person saw, what the cause was, how long it had existed, how it was found, and what will prevent it next time. These notes cost five minutes and build a library of lessons. After a few months the notes show patterns, such as “most surprises come from overrides older than six months,” which tell you exactly where to improve your process.

A few overrides cost nothing. Thousands need thought. This chapter explains how they flow to your application and what changes at scale.

How the answer reaches the application

In the usual remote evaluation mode, the application asks Flagsmith’s servers for the flags of an identity, and Flagsmith works out the answer, including any override, and replies. The SDK then keeps the answer in memory. A new override does not appear in the application until the application asks again or its timer for refreshing expires. This delay explains many “I made the change and nothing happened” reports.

Local evaluation

With local evaluation, a back-end server downloads the rules and states of an environment and decides by itself, from memory, for every identity. Whether identity overrides are included in what it downloads has depended on version and settings, and very large numbers of overrides can make that download bigger. If you plan to use local evaluation and to keep many overrides, read the current documentation and test the behaviour with one example override before relying on it.

sequenceDiagram
    participant H as Human
    participant FS as Flagsmith
    participant SDK as Application SDK
    participant U as Customer screen
    H->>FS: Create override for customer-884
    Note over SDK: SDK still holds the old answer in memory
    SDK->>FS: Refresh flags for customer-884
    FS-->>SDK: New answer including the override
    SDK-->>U: Screen changes after refresh
    

Practical advice

Choosing the refresh rhythm

The rhythm at which an application asks for fresh flags is a design choice with a trade-off. A short rhythm, such as every few seconds, makes new overrides appear quickly but increases traffic and battery use. A long rhythm, such as once per session, is cheap but slow to show changes. Many applications ask at start-up, again after sign-in, and then on a timer of several minutes. For urgent protective overrides, such as disabling a harmful feature for one customer, support can ask the customer to restart the application, which forces a fresh request. Decide the rhythm once, write it in your runbook, and tell support the number, so that nobody wastes an hour wondering why a correct change has not yet appeared.

Every strong tool has a price. Seeing both sides honestly helps you decide how much to use.

Key trade-offs

Estimating the real cost of an override

An override looks free because it takes one minute to create. Its true cost is spread across time: the minute to create it, the minutes of every later person who wonders why a customer is different, the review time each month, the risk of a surprise, and the final minute to remove it. A single override costs very little in all. A hundred forgotten ones cost a great deal, because each adds a small piece of confusion to every investigation. When you decide between an override and a segment, count the whole life of the exception, and not only the first minute. A segment costs more to set up and less to live with, and for anything that will last, that is the better trade.

Teams have faced these problems many times. Patterns are the habits that keep working. Anti-patterns are the traps that keep catching people.

Good patterns

Anti-patterns

flowchart TB
    subgraph BAD["Anti-pattern: sprawl"]
        B1["Feature"] --> B2["Override for person 1"]
        B1 --> B3["Override for person 2"]
        B1 --> B4["Override for person 3"]
        B1 --> B5["Override for person 4"]
        B1 --> B6["Override for person 5 and more"]
    end
    subgraph GOOD["Pattern: promote to a segment"]
        G1["Feature"] --> G2["Segment: design partners"]
        G2 --> G3["Trait design_partner equals true"]
    end
    BAD --> GOOD
    

Spotting sprawl early

Sprawl does not arrive in one day. It arrives as one extra override each week, each of them reasonable on its own. Watch for three early signs. The count of overrides only goes up and never down. Several overrides on one feature share the same reason. Engineers say “I think that customer has an override” without being sure. Any one of these signs is enough to call a short clean-up. A clean-up in the first month is a quiet afternoon. A clean-up after two years is a project.

If you remember only one chapter for daily work, make it this one. It gathers the habits that matter most.

Best practices

Common mistakes

Questions for a design review

• Why is this a personal override and not a segment?
• Who owns it, and when does it end?
• Does it enable something that costs money?
• What does the person see after it ends?
• How will we know it was removed?

A gentle adoption path for a new team

The idea of giving one person a special answer is old. Large companies have done it for years, under many names. Here are the common patterns.

Large technology companies

A famous warning: Knight Capital

In 2012, the trading firm Knight Capital lost a very large sum in under an hour after a deployment went wrong. Reports said that old code, controlled by a switch whose meaning had been reused for something new, was activated on one server that had not received the update. The lesson is about control and memory: old switches, forgotten exceptions, and reused names are dangerous. An override that nobody remembers is a small cousin of that old switch, waiting to surprise someone.

An invented story to tie it together

Leena runs the platform team at a company that sells online tutoring. She wants to launch a new whiteboard tool. She follows these steps.

Short answers to the questions beginners ask most.

We began with a principal who wrote a small note for one child and left the school rule alone. We end with a system that does the same for any product, safely.

An identity override is a feature state attached to one identity, for one feature, in one environment. It is the most specific layer in Flagsmith’s order of authority: it is checked first and beats segment overrides, percentage rules, variations, and defaults. It can set the enabled position, the value, or a chosen variation, and it applies only to the person it was made for.

Its strength is speed and certainty, and its weakness is invisibility. It does not appear on the feature screen, it does not scale to groups, and it is easily forgotten. For that reason, good teams keep overrides rare, give each a reason and an end date, record them in a register, announce them in a channel, review them every month, and promote repeated exceptions into traits and segments. They remember that environments are separate, that identifiers must match exactly, that new answers appear when the application refreshes, and that a flag is not a lock: the server must check permission itself.