A flag looks small, but it can change what every customer sees. Power that large needs deliberate limits.

One click, many customers

Changing code normally takes a chain of steps: write it, review it, test it, build it, deploy it. Each step is a chance for someone to notice a problem. A flag change skips most of that chain on purpose. That is the whole point of flags: they let you change behaviour quickly, without a deployment. But speed cuts both ways. The same quickness that lets you switch off a broken feature in seconds also lets a mistaken click break a working one in seconds.

The three things that go wrong

Without clear access rules, three kinds of trouble appear again and again. The first is accident: a new team member opens the Production environment, sees a flag that looks unused and switches it off. The second is overreach: a contractor who needed to read flag values for one week still holds full control months later. The third is confusion: after an incident nobody can say who was allowed to do what, so the lessons are vague and the same mistake returns.

What good access control gives you

A short list of terms describes the whole subject. Learn them once and every later chapter reads easily.

flowchart LR
    U["User"] --> G["Group"]
    U --> R["Role"]
    G --> R
    R --> P["Permissions"]
    P --> S["Scope: organisation, project or environment"]
    S --> A["Allowed or refused action"]

Read the figure from the left. A user may belong to groups and may hold roles directly. Groups can hold roles too, so everyone in the group inherits them. A role is a bundle of permissions. Each permission is attached to a scope, which is the level where it applies: the whole organisation, one project or one environment. When someone tries to do something, Flagsmith checks whether any of their permissions, at the right scope, allow that action. If so the action succeeds. If not, it is refused.

RBAC is one of several ways to decide who may do what. Knowing its shape tells you what it solves well and where it stops.

The core idea

In Role-Based Access Control, you do not give permissions to people directly. You give permissions to roles, and you give roles to people. The benefit appears when staff change. When Meera moves from the checkout team to the search team, you change her role, and all the right permissions follow. Nobody has to remember the twenty small grants she held a year ago and then forgot.

Three common models

Flagsmith’s permission system is mainly role-based, with groups and with scopes that make it feel a little like an access control list at the project and environment levels. You choose who may do what, at which level, and you do it through people, groups and roles.

The principle of least privilege

Least privilege means giving each person the smallest set of permissions that lets them do their job, and no more. It is the most useful rule in access control. If a developer only needs to change flags in Development and Staging, they should not be able to change Production. If an analyst only needs to read, they should not be able to write. Least privilege does not mean mistrust. It means that when something goes wrong, which it will, the damage has a boundary.

What RBAC does not do

• It does not decide which of your customers sees which feature. That is the job of segments and targeting, which control end users, not team members.
• It does not stop a trusted person from making a bad decision. It limits who can make the decision, and approvals help review it.
• It does not replace strong sign-in. A perfect permission design is useless if a password is shared.
• It does not protect secrets stored carelessly in flag values.

Flagsmith nests its things like boxes inside boxes. Permissions are attached to a box, and they apply to what is inside it.

The hierarchy

At the top sits the organisation. Inside it are projects. Inside each project are environments, and flags, segments and tags. Each level has its own permissions. The deeper the level, the narrower the power.

flowchart TD
    O["Organisation: company, users, groups, billing"] --> P1["Project: Web Shop"]
    O --> P2["Project: Mobile App"]
    P1 --> E1["Environment: Development"]
    P1 --> E2["Environment: Staging"]
    P1 --> E3["Environment: Production"]
    P1 --> F["Flags, segments and tags, shared across the project"]
    E3 --> S["Flag states, identities and segment overrides, per environment"]

Which level holds what

Why this split is clever

A flag’s definition, its name and kind, is shared across the project. Its state, on or off and the value, is held separately in each environment. That means you can allow a developer to create a flag in the project and change its state in Development, while keeping Production out of reach. The levels give you a way to say “trusted to experiment, not trusted to release”.

Inheritance: higher powers flow down

Permissions at a higher level generally cover what lies below. An organisation administrator can do everything in every project. A project administrator can do everything in that project’s environments. Someone with a permission only at one environment has it only there. Think of it as water running downhill: it flows to everything beneath, never upwards.

The organisation is the top box. The decisions made here set the outer walls for everything else.

Two basic kinds of member

Every person in an organisation is, at the simplest level, either an administrator or an ordinary user. An organisation administrator can manage the organisation itself: invite and remove people, create and edit groups, create projects, manage billing and sign-on, and see everything. An ordinary user can only do what they are explicitly given in projects and environments, which at first is nothing at all.

How people join

People usually join by invitation. An administrator enters an email address, optionally chooses a starting group or role, and Flagsmith sends a link. In organisations that use single sign-on, people may be created automatically the first time they sign in with the company identity system, according to settings an administrator chooses. Whichever route you use, check afterwards what the new person can actually see.

Keep the administrator list short

The administrator role is the master key. A good rule is that very few people should hold it: a small, named set who understand the consequences, plus a way for a second person to cover when someone is away. The more administrators there are, the more places a stolen password can lead to everything, and the harder it becomes to know who changed a setting. For daily work, administrators should often use ordinary accounts and keep the administrator account for administrative tasks.

Groups are the first tool for taming growth. They turn a hundred separate decisions into a handful.

What a group is

A group is a named list of users, such as “Checkout engineers”, “QA”, “Support” or “Release managers”. You give permissions to the group at the organisation, project or environment level, and every member receives them. When a member joins the group they gain the rights, and when they leave the group they lose them. Nobody has to edit twenty permission screens when a team changes.

Group admins

Many setups allow a group to have its own administrators, who can add and remove members of that group without being organisation administrators. This lets a team lead manage their own team while an organisation administrator manages the rules. Whether and how this works depends on your plan and version, so check it in your dashboard.

Designing good groups

Why groups beat direct grants

A project holds the definitions that every environment shares. Its permissions decide who shapes the catalogue of flags.

The usual project permissions

Flagsmith’s project-level permissions are listed in the dashboard. Names and details differ between versions, but they generally cover the following ideas.

Why “delete feature” is special

Deleting a flag removes its definition from the project, which means every environment loses it at once. The code that still asks for that flag will fall back to its default. This is why deletion is usually given to fewer people than creation. Making a flag is easy to undo. Removing one can, if code still depends on it, change behaviour everywhere.

Why “manage segments” matters

A segment defines a group of end users by rules, such as “customers in India on the premium plan”. A change to a segment’s rules changes who receives every flag that uses it, in every environment where that segment is used. Editing a segment is therefore a kind of release, even though no flag was touched. Give this permission with the same care as changing a flag in Production.

The environment is where the risk is sharpest. Production’s permission list is the one to read twice.

The usual environment permissions

Separating proposing from approving

The pair “create change request” and “approve change request” is the most useful split on the list. A person with only the first can say “I would like this flag changed”, but cannot make it happen. A different person with the second decides. This gives a classic two-person rule: no single person can both prepare and release a change to Production. The approvers should not be the authors of the changes they approve, and your process should say so clearly.

Reading is not harmless

Viewing sounds safe, but flag values can hold real information: a partner’s URL, a limit, a message for customers, or an internal setting. Identities and traits can hold personal data about customers. So even “view” permissions deserve thought, particularly in Production, and particularly for outside contractors.

flowchart TD
    D["Developer: create change request"] --> Q["Pending change request in Production"]
    Q --> A["Approver: approve change request"]
    A --> L["Change goes live"]
    D -. "cannot approve own change" .-> X["Blocked by process and, in many setups, by the product"]

Groups say who. Roles say what. Together they let you write rules once and apply them many times.

What a role is

A role is a named set of permissions, defined once, and then given to users or groups. For example, a role called “Release manager” might contain: view project, view environment, update feature state in Staging and Production, and approve change requests in Production. Instead of ticking those boxes for every release manager in every project, you tick them once on the role and attach the role to a group.

Availability and the built-in alternative

Custom roles, with permissions you choose yourself, are usually part of higher paid plans. If you do not have them, the same effect can still be reached by granting permissions to groups directly, project by project and environment by environment. Roles save effort and reduce mistakes, but they are a convenience, not the only route. Confirm what your plan offers.

Example role catalogue

Roles and groups together

The cleanest setup is: users belong to groups that mirror teams, and roles are attached to groups. When a person changes team, you move them between groups and the roles follow. You rarely attach roles directly to individuals, except in a deliberate one-off, and when you do, you record why.

Sometimes an environment is too big a box. You may want a team to touch some flags and not others.

The problem of big projects

A busy project can hold hundreds of flags, owned by different teams. If the checkout team can change every flag in Production, they can also change the search team’s flags by accident. Environment-level permissions alone cannot express “only your own flags”.

Tags as labels

A tag is a coloured label attached to a flag, such as “checkout”, “search” or “experiment”. Tags help people find and filter flags. In some plans and versions, tags can also be used in permission rules, so that a role applies only to flags with certain tags. Where this exists, it is an elegant way to give each team control of its own corner of a shared project. Whether it is available, and exactly how it behaves, depends on your plan and version, so check your documentation.

If you do not have tag-based rules

Without such rules you have three sensible fallbacks. You can split teams into separate projects, so each team’s flags live in their own box. You can use naming conventions and review them through change requests. Or you can rely on approvals: anyone can propose, but the owning team must approve changes to their flags.

A person can receive rights from several places at once. The final result is what they can actually do, called their effective access.

Rights add up

In most RBAC systems, including Flagsmith’s, permissions are additive. If a person is allowed to do something through any route, they are allowed. Imagine Anil belongs to the “Developers” group, which can update Development. He also belongs to the “Release managers” group, which can approve Production changes. He also has one direct grant to view the audit log. His effective access is the sum of all three. Removing one group takes away only that group’s share.

Why this surprises people

Additive access means that taking away a permission in one place does not guarantee a person loses it. If the same permission also arrives through another group, they keep it. Many “I removed it but they can still do it” puzzles end here. The cure is to look at every route: direct grants, each group, each role and the administrator flags at higher levels.

flowchart LR
    G1["Group: Developers"] --> E["Effective access of Anil"]
    G2["Group: Release managers"] --> E
    D["Direct grant: view audit log"] --> E
    H["Higher-level administrator right, if any"] --> E

A checking routine

Good access control is designed on paper first, from jobs and risks, not clicked together one request at a time.

Step 1: list the jobs, not the people

Write down what work happens around flags: developers create and change flags in test stages; testers check behaviour in Staging; release managers move changes into Production; product staff adjust audiences; support staff look up why one customer sees something; auditors review history; platform staff manage environments and keys. Each of these jobs becomes a candidate role.

Step 2: grade the environments by risk

Step 3: build a matrix

A permission matrix is a table with roles down the side and actions across the top. It is the single most useful document in access control. It can be read in a minute, reviewed by a manager and compared with what Flagsmith actually shows.

Step 4: decide the exceptions in advance

Emergencies will happen. Decide beforehand who may bypass the normal rule, how they record the reason and how the bypass is reviewed afterwards. An exception planned in calm is safer than an exception improvised at three in the morning.

flowchart TD
    J["List the jobs"] --> R["Group jobs into a few roles"]
    R --> E["Grade environments by risk"]
    E --> M["Build the permission matrix"]
    M --> X["Plan emergency exceptions"]
    X --> I["Implement in Flagsmith"]
    I --> V["Review on a schedule"]
    V --> J

Permissions answer “may this person act?”. Approvals answer “has someone else agreed?”. The two work best together.

What a change request does

When an environment requires change requests, a person with only proposal rights cannot change a flag directly. They write down the change, including the new state, and submit it. The change waits as a pending request, visible to the approvers. An approver reviews it, perhaps discusses it, and approves or rejects it. Only after approval does it become the live state. Where your plan supports it, the number of approvers needed can be set, and the author may be barred from approving their own request.

Which environments should require them

Not every environment needs this. Development and personal test stages should usually be free, so people can move fast. Production nearly always benefits. Staging is a judgement call: if it feeds important tests or releases, a lighter rule may help.

Choosing approvers

The cost of approvals

Approvals add a little time and a little friction. During an incident, that friction can matter. A mature team plans for this: a fast route for emergencies, with a named person who can approve at any hour, and a review the next morning. Without that route, people will find ways around the rule, which is worse than no rule.

People are not the only ones who talk to Flagsmith. Applications and scripts do too, and they need their own carefully limited keys.

Three families of keys

Why the difference matters

A client-side key lives in code that anyone can download, so it must be safe to expose, and it only returns what a single user should see. A server-side key reveals your whole rule set, including segment rules, so keeping it on a server is essential. An Admin API token can change things, so it should be treated like a password with the same powers as its owner. Your permission design is not complete until it covers these too.

Limiting machine access

• Use separate keys for each application and environment, so one leak has a boundary.
• Where your plan offers organisation-level API keys with roles attached, give automation a role with only the permissions it needs, rather than a personal token tied to a person who may leave.
• Store keys in a secrets manager, never in source code, chat or documents.
• Rotate keys on a schedule and immediately after any suspicion.
• Delete keys that no longer have a purpose.

flowchart LR
    M["Mobile or web app"] -->|"client-side key"| F["Flagsmith: flags for one user"]
    B["Backend service"] -->|"server-side key"| F
    C["CI pipeline or script"] -->|"Admin API token with a role"| F
    H["Human in the dashboard"] -->|"sign-in plus roles"| F

Permissions decide what a person may do. Sign-in decides whether the person is who they say they are. Both must be strong.

Single sign-on

Single sign-on lets people use their company identity, from systems such as Okta, Microsoft Entra ID or Google Workspace, to sign in to Flagsmith, instead of a separate password. The benefits are large. When someone leaves the company and their identity is disabled, they lose access everywhere at once. Password rules, lockouts and multi-factor checks are managed in one place. Availability of SSO methods such as SAML or OpenID Connect depends on your plan and whether you self-host, so confirm in the documentation.

Two-factor authentication

Two-factor authentication asks for something you know, a password, plus something you have, such as a code from a phone app. Even if a password leaks, an attacker cannot easily sign in. Where SSO is not used, two-factor sign-in on every account that can change Production is one of the best protections you can add. Where it is used, enforce it in the identity system.

Automatic provisioning

Provisioning means creating, updating and removing accounts automatically from the company directory. Some setups can map directory groups to Flagsmith groups, so when someone is added to the “Payments engineers” group in the directory, they receive the matching Flagsmith permissions with no extra step. Support for this varies, so check what your plan and version provide. The principle is worth adopting even where tools are limited: one source of truth for who belongs in which team.

Access control prevents bad actions. The audit log records the actions that did happen, so you can learn from them.

What it records

The audit log is a time-ordered list of changes: who changed which flag, in which environment, to what, and when. It usually records flag state changes, segment edits, change request approvals and similar events. Exactly which events are recorded, and how long they are kept, depend on your plan and version. Who may read the log is itself a permission, because the log reveals what changed and may include values.

Four jobs for the log

Making the log more useful

The log is only as clear as the habits around it. Ask people to write a short reason with each important change. Link change requests to tickets. If your plan supports sending the log to other systems, for example through webhooks to a central log store, do so, because a copy kept elsewhere cannot be quietly altered from within Flagsmith.

Limits of the log

The log shows that something changed, not always why. It cannot undo harm. And it only helps if somebody reads it. A log nobody reviews is a diary kept in a locked drawer.

The right amount of structure depends on how many people and how much risk you have. Too little invites accidents. Too much invites workarounds.

Pattern A: the small team (under about ten people)

Everyone knows everyone. Keep it simple: two or three administrators, one group for developers with rights in Development and Staging, and Production changes limited to a short list of senior people. Change requests may be optional for Staging but should apply to Production. A single page describing who can do what is enough.

Pattern B: the growing company (tens of people, several teams)

Here groups become essential. Create one group per team, a “Release managers” group and a viewers group for support and management. Use roles, where available, to bundle permissions. Require change requests in Production, with approvers outside the author’s own team where possible. Start a quarterly access review.

Pattern C: the large organisation (hundreds of people, many products)

Use one project per product, or per major service, so teams have their own walls. Connect sign-in to the company identity system and map directory groups to Flagsmith groups. Keep a central platform team that owns organisation settings, and delegate project administration to product owners. Add audit log export to a central store and formal reviews with security and compliance.

flowchart LR
    S["Small: few admins, simple rules"] --> G["Growing: groups, roles, change requests"]
    G --> L["Large: per-product projects, SSO mapping, log export"]

The shape of your projects decides how easy or hard your permissions will be. Choose it with access in mind.

Three layouts

Questions to decide

• Do the same people own all the flags, or do different teams own different flags?
• Do flags need to share segments across products?
• Does one product have special sensitivity, such as payments, that should be walled off?
• How many projects can your administrators realistically look after?

Environments inside projects

Keep the same environment names in every project: Development, Staging, Production. Consistent names make permission matrices readable and let one runbook serve every team. Add extra environments, such as demo or load-test stages, only with a clear owner and a clear purpose, because every environment is another place for permissions to drift.

Short-term people are the most common source of leftover access. Plan their exit on the day they arrive.

The rules for temporary people

Temporary elevation

Sometimes a normal person needs extra power for a short time, such as a developer helping with a Production release. Rather than adding the right permanently, add them to a special group for the duration and remove them afterwards. Record who, why and for how long. Some organisations automate this with a request tool, but even a manual note and a calendar reminder is far better than leaving the permission in place for ever.

Strict rules must still allow a fast fix when something is burning. Plan the emergency door before you need it.

What “break glass” means

The phrase comes from fire alarms behind a pane of glass: you may break it, but only in a real emergency, and breaking it is noticed. In access control, a break-glass procedure is a pre-agreed way for a small number of people to bypass the normal rules quickly, with a clear record and a review afterwards.

Design points

• Name who may use it, usually the on-call lead and a deputy.
• Decide what it permits: usually changing a specific flag in Production, not unlimited power.
• Require a written reason in the incident channel at the time.
• Review every use the next working day: was it necessary, and was the action right?
• Test it twice a year in a calm rehearsal, so that it works when needed.

sequenceDiagram
    participant O as On-call engineer
    participant L as Release lead
    participant F as Flagsmith
    participant T as Team channel
    O->>T: Declare incident and name the flag
    O->>L: Ask for emergency approval
    L->>F: Approve change or apply it directly
    F-->>T: Audit log entry appears
    O->>T: Confirm effect and write the reason
    L->>T: Next day: review the use

Clicking permissions into a dashboard works for a while. Writing them down as reviewable, repeatable configuration works much longer.

Why not only click

Hand-made permissions drift. Someone adds a quick exception, someone else forgets to remove it, and after a year nobody knows what is intended. Infrastructure as code, a way of describing settings in files that tools apply automatically, fixes this by keeping the intended state in version control, where changes are reviewed like any other change.

What can be automated

Flagsmith offers a management API, and a community and vendor-supported Terraform provider exists for many Flagsmith resources. Whether a particular permission, role or group can be managed that way depends on the version of the provider and of Flagsmith, so check what is covered before relying on it. Common candidates are projects, environments, tags, groups and role assignments.

Safe habits for automation

• Give the automation its own limited credential, never a person’s token.
• Require code review for every permission change, just like Production code.
• Run a “plan” or dry run first and read what will change.
• Alert when someone changes permissions by hand outside the automation.

A permission model is a piece of design, and design can be wrong. Test it the way you test anything important.

Test both directions

Most people only test that the right person can do the right thing. Just as important is the opposite: that the wrong person cannot. A test suite for access has two columns of cases, “should succeed” and “should be refused”.

Use test accounts

Create a few dedicated test accounts that sit in each group, such as “test-developer” and “test-viewer”. Sign in as each and try the cases above. Do this when you first design the model, after any major change, and on a schedule. Keep test accounts clearly labelled, protect them like real ones, and remove them if they become unused.

Record the results

Write down each test, who ran it, the date and the result. A simple table in a shared page is enough. The record proves that controls were tested, helps the next person repeat the tests, and shows trends over time, such as the same gap appearing after every reorganisation. When an auditor asks how you know your permissions work, you can point to evidence instead of memory. Keep the record short, honest and easy to update, or it will not be kept at all.

Rehearse the dark days

Beyond routine cases, rehearse awkward ones. What happens when the only release manager is on holiday? What happens when the identity provider is down and nobody can sign in? Is there a local administrator who can still get in, safely protected, to repair things? Finding these gaps in a rehearsal is cheaper than finding them in an incident.

Access control decays. People change jobs, projects end and exceptions pile up. Regular reviews keep the model true.

What an access review is

An access review is a scheduled check where someone looks at who holds what and asks whether each right is still needed. It sounds dull, but it is one of the highest-value habits in security, because the commonest problem is not a clever attack. It is access that nobody remembered to remove.

A simple quarterly review

Signals worth watching

Two complaints dominate: “I cannot do what I should” and “they can do what they should not”. Both have a method.

Problem 1: someone cannot do something

flowchart TD
    S["A person reports: I cannot do X"] --> A["Are they signed in with the right account?"]
    A --> B["Do they belong to the expected group?"]
    B --> C["Does the group or role hold the permission?"]
    C --> D["Is it granted at the right level and environment?"]
    D --> E["Does the environment require change requests?"]
    E --> F["Is the plan or version missing that feature?"]

Problem 2: someone can do something they should not

Remember that rights are additive. Look for other groups, direct grants and administrator flags that reach the person. Check whether the right is held at a higher level that flows down. Then look at API tokens they own, because a token may carry rights the person’s dashboard role does not seem to show.

Common causes and cures

RBAC is one layer of a larger defence. Seeing the whole picture shows where it helps and where other layers must carry the load.

Threats that RBAC addresses

Sensitive data inside Flagsmith

Two places deserve special care. Flag values can hold text, numbers or structured settings, and people sometimes put sensitive things in them. A rule of thumb: never store passwords, private keys or personal data in flag values. Identities and traits describe individual end users and may contain personal data. Restrict who may view identities in Production, and store only what you truly need, in line with the privacy laws that apply to you, such as GDPR in Europe or India’s data-protection law. Laws differ and change, so consult your legal and privacy teams for requirements specific to you.

Separation of duties

Separation of duties means that no single person can complete a sensitive process from start to finish. In flag terms: the person who proposes a Production change is not the person who approves it, and the person who administers permissions is not the person who audits them. Auditors often look for this pattern explicitly.

Self-hosted and cloud differences

If you use Flagsmith’s hosted service, the vendor operates the platform and you control the permissions inside it. If you self-host, you also control the servers, databases, network, backups and upgrades. Then the surrounding security belongs to you too: who can reach the database, who holds server access, and how backups containing flag data and keys are protected. RBAC inside the tool cannot protect you from someone who can read the database directly.

An anti-pattern is a habit that looks sensible and causes trouble later. These five are the most common in access control.

RBAC is powerful, and it is not free. Knowing the costs helps you spend on it wisely.

Choosing how strict to be

Where to relax and where to tighten

Experienced teams repeat a short list of habits. New teams repeat a short list of mistakes. Here are both.

Habits worth building

Mistakes to catch early

To finish, here is one imaginary company taken from an open, messy setup to a clean RBAC design, using everything in this guide.

BrightCart, the imaginary online shop, has grown from eight to ninety engineers in three years. It uses one Flagsmith project for its web shop, a mobile app project and a payments project. Its early habits remain: twenty people are organisation administrators, a shared login named “release-bot” is used by anyone who needs to change Production, and a personal Admin API token of an engineer who left last year still runs the nightly deployment script. A recent incident, in which a flag for a payment method was switched off at midday by someone who thought it was unused, is the trigger for a clean-up.

What would have gone wrong without the clean-up?

Without it, the next unused-looking flag would have been switched off by a well-meaning engineer, and no approval would have caught it. The leaver’s token could have been found by anyone with access to the old repository. A new contractor would have been given the shared login. And when the auditors asked who could change Production, the honest answer would have been “nearly everyone, and we cannot say who did”. Each of these is an ordinary risk, and each is closed by the habits in this guide.

A flag is born, grows, is released, and is finally retired. Different people should hold the pen at different stages.

Stage by stage

Ownership is a form of access

Every flag should have a named owner, a team or a person. Ownership tells everyone whom to ask before changing a flag and who must clean it up. Flagsmith lets you add descriptions and tags to flags, and these are good places to write the owner and the purpose. A flag without an owner is how “this looks unused, I will switch it off” accidents begin.

The danger of old flags

Old flags are a quiet risk. Nobody remembers them, yet code may still depend on them. A common safe pattern is to make removal a two-step act: first the owner marks the flag as ready to retire and removes it from code, and only after code is deployed and quiet does a senior person delete the flag. Keeping delete rights narrow protects the second step.

flowchart LR
    C["Create: developer"] --> T["Test: developer and tester"]
    T --> R["Release: reviewed change"]
    R --> O["Operate: owner"]
    O --> D["Retire: owner proposes, senior deletes"]

Some of what Flagsmith holds is about your customers, not your team. Access to it needs the strictest care.

What identities are

An identity is Flagsmith’s record of one end user of your product, identified by a unique string you provide. It can carry traits, which are small facts about the user, such as their plan or country. Segments use traits to decide who gets which feature. In many setups identities are created on the fly as users appear, so the list can grow large and contain personal information.

Why it matters for access

People with permission to view identities can see these records. People with permission to manage identities can edit them, and editing a trait can change which features a customer receives. A support agent might legitimately need to look up one customer. Almost nobody needs to browse them all. So separate “view and manage identities” from the general “view environment” permission, and give it narrowly, particularly in Production.

Reducing the risk at the source

Flagsmith can connect to other tools. Each connection is another place where access must be thought through.

Two directions

Connections go both ways. Inbound, other tools such as pipelines or ticket systems call Flagsmith’s management API, using a token. Outbound, Flagsmith tells other tools about events, for example by webhooks, which are messages sent to a web address when something changes, or by integrations with chat, monitoring and analytics services. Which integrations exist depends on your version and plan.

Questions for every connection

Managing change in integrations

Treat integration settings like any other sensitive configuration. Keep a list of them with owners, restrict who may add or edit them, and review the list when you review keys. A webhook that sends flag changes to a chat channel is helpful. A webhook that sends them to a forgotten server is a leak.

Most teams do not start with a perfect design. They start open, and tighten later. Doing that without breaking work needs a plan.

The risks of tightening

If you remove rights suddenly, scripts fail, releases stall and people look for workarounds. If you tighten too slowly, the risk stays. The goal is a steady, announced, reversible move.

A safe migration path

flowchart LR
    O["Open access"] --> L["Learn from the audit log"]
    L --> B["Build groups and roles alongside"]
    B --> A["Announce and cut over Production first"]
    A --> R["Review, adjust, repeat"]

Rules without an owner decay. Someone must be responsible for the permission model, in writing and by name.

Who owns what

A short written policy

A policy does not need to be long. One page can state the principles (least privilege, two people for Production, individual accounts), the roles and what they mean, how to request access, how long contractors may keep it, how emergencies are handled and when reviews happen. People will read a page. They will not read a manual.

Training and onboarding

Rules that nobody understands are rules that people work around. When a new engineer joins, spend fifteen minutes explaining the levels, the roles, why Production needs a second person and how to ask for more access. Show them the permission matrix and the break-glass route. Repeat a short version once a year for everyone. People who understand the reason behind a rule follow it more willingly, and they notice quickly when a rule is not working as intended.

Keeping a decision log

Whenever you grant an unusual right or make an exception, write down who agreed, why, and when it should be reviewed. A simple shared page is enough. Months later, nobody will remember the reason, and the log turns a mysterious permission into an understood decision that can be safely kept or removed.

Handling requests

Make asking for access easy and visible. A simple form or ticket, with a named approver and a record of why, is enough. If asking is painful, people borrow someone else’s login. If asking is simple and quick, they follow the rules happily.

You cannot improve what you cannot see. A few simple measures show whether the model is healthy.

Useful measures

Reading the numbers

Numbers are prompts for questions, not verdicts. A rise in emergency uses may mean a real incident period, or a rule that needs changing. A slow grant time may mean too few approvers. The point is to notice drift early, discuss it calmly and adjust before it becomes an incident.

Short, direct answers to the questions people ask most about RBAC in Flagsmith.

RBAC lets you give many people useful power over flags without giving anyone more than they need. A few ideas carry nearly all the value.