Before connecting anything, it helps to know exactly what you are connecting.

Feature flags in one minute

A feature flag is a switch in your software that decides whether a feature is visible. Instead of hiding a new button by deleting code, you wrap the button in a check: “if the flag is on, show it.” Later, you flip the flag in a dashboard and the button appears or disappears without a new release.

A remote config value is a close cousin. Instead of just on or off, it holds a number, a piece of text or a small block of structured data. For example, a flag can say “show the banner,” while a config value says what the banner text should be, or how many items to show per page.

The building blocks you will see again and again

Flagsmith organises things in layers. An organisation is your company account. Inside it sit projects, which usually map to one product or service. Inside each project sit environments, such as development, staging and production. The same flag exists in every environment, but it can be on in development and off in production.

Flagsmith can also decide a flag differently for different people. An identity is one user, known by an ID your app sends. A trait is a small fact about that user, like their plan or country. A segment is a group of users who share traits, such as “all users on the paid plan.” This lets you say, “turn this on only for the beta group.”

The island problem

If Flagsmith stood alone, it would be an island. Your analytics tool would not know which users saw which variation. Your monitoring graphs would not show when a flag was flipped. Your chat channel would stay silent while production changed. Your issue tracker would have no idea which ticket a flag belongs to.

Integrations are the bridges. They carry information out of Flagsmith to the places where people already look, and in some cases they carry actions back in. A well-chosen set of bridges turns a flag change from a hidden event into a visible, searchable, measurable one.

One picture first, then the details.

Most integrations in Flagsmith are outbound. That means Flagsmith pushes information to another system when something happens. A smaller number of connections are inbound or two-way, where another tool calls Flagsmith or reads from it. Keeping that direction in mind makes every integration easier to reason about.

flowchart LR
  Dev["Developer or Product Manager"] --> UI["Flagsmith Dashboard"]
  UI --> Core["Flagsmith Core: Flags, Segments, Audit Log"]
  App["Your App with Flagsmith SDK"] -->|"asks for flags"| API["Flagsmith API or Edge API"]
  API --> Core
  Core -->|"flag state per user"| Analytics["Analytics: Segment, Amplitude, Mixpanel, Heap, RudderStack"]
  Core -->|"change events"| Observe["Observability: Datadog, New Relic, Dynatrace, Grafana"]
  Core -->|"notifications"| Chat["Slack"]
  Core -->|"webhooks"| Custom["Your Own Services"]
  Core -.->|"links"| Code["GitHub and Issue Trackers"]

Reading the diagram

On the left, two kinds of people touch Flagsmith. Humans use the dashboard to change flags. Your running application uses an SDK, which is a small software library that talks to Flagsmith for you. The SDK asks the Flagsmith API, “What are the flags for this user?” and gets an answer in a fraction of a second.

In the middle sits the core, which stores flags, segments and the audit log. The audit log is a diary of who changed what and when. On the right are the bridges. Some of them fire when a human changes a flag. Others fire when your app asks about a particular user.

Three places an integration can live

Integrations are configured at different levels. Understanding the level tells you how far a setting reaches.

In general, tools that watch your whole product, such as monitoring platforms, are set up once for a project. Tools that must tell production apart from staging, such as analytics keys, are set up per environment. Organisation-wide settings, like single sign-on, apply to everyone. When in doubt, look at where the dashboard places the setting, because that tells you its reach.

Sorting integrations into families makes the long list easy to remember.

A new engineer can feel overwhelmed by a long list of logos. A better method is to ask what job each integration does. Almost every integration falls into one of four jobs: measure, watch, tell or connect.

Why this grouping works

When someone asks, “Can Flagsmith work with our tool?” you can answer by checking the job. If the tool is a chart-drawing monitoring product, think observability. If it is a place where product managers study user behaviour, think analytics. If it is a chat room, think notifications. If it is none of those, think webhook or API.

One event, many listeners

A single flag change can feed several families at once. A product manager enables a feature for ten percent of users. Slack announces it. Datadog gets a marker on the dashboards. Your analytics tool begins to receive the flag state for users who open the app. A webhook wakes up an internal service. Nobody had to copy information between tools by hand.

The rest of this guide takes each family in turn, then looks at security, failure handling and good design.

Analytics tools answer “what did people do?” Flagsmith adds “and which version were they looking at?”

What problem they solve

Suppose you launch a redesigned signup page to half your users. A week later your analytics tool shows that signups went up. Is that because of the redesign, or because of a marketing email sent the same week? Without knowing who saw the new page, you cannot tell. You need each user’s profile in analytics to carry a note: “this person saw the new signup page.”

That is exactly what the analytics integrations provide. When Flagsmith works out the flags for a user, it can pass those flag states to the analytics tool as extra facts about that user. These facts are usually called traits or user properties, depending on the tool.

The tools in this family

Segment and RudderStack are customer data platforms. Think of them as a central mailroom: you send data in once, and they forward it to many destinations. If you connect Flagsmith to one of these, the flag states can flow on to every tool wired to that mailroom.

Amplitude, Mixpanel and Heap are product analytics tools. They focus on funnels, retention and behaviour. Connecting Flagsmith directly to them lets you slice any chart by flag state, for example, “show conversion for users where the new checkout is on versus off.”

How the data moves

sequenceDiagram
  participant U as User Browser
  participant S as Flagsmith SDK
  participant F as Flagsmith API
  participant A as Analytics Tool
  U->>S: User signs in
  S->>F: Identify user and request flags
  F->>F: Evaluate flags and segments
  F-->>S: Return flag values
  F-)A: Send flag states as user traits
  A->>A: Store traits with user profile

Read the figure from top to bottom. The user signs in, so your app now knows who they are. The SDK tells Flagsmith, “Here is user 4821, what are their flags?” Flagsmith checks the rules and segments, answers the app, and also forwards the resulting flag states to the analytics tool you connected. The analytics tool saves them on the profile for user 4821.

Two details matter. First, this works for identified users, because analytics needs a stable user ID to attach the facts to. Anonymous traffic with no ID gives the integration nothing to hang data on. Second, the key you enter in Flagsmith, such as a write key or API key, is set per environment so that production data does not mix with test data.

Do not confuse two kinds of “analytics”

Flagsmith also has its own built-in flag usage counting, where SDKs can report how often a flag was evaluated. That is a separate feature that stays inside Flagsmith. The third-party analytics integrations in this chapter are about sending flag states out to your external analytics tool. They answer different questions, and you can use both.

A short checklist for good analytics setups

• Use stable, non-personal user IDs, such as an internal number, not an email address.
• Name flags clearly so the trait names in analytics are easy to read months later.
• Connect production to your production analytics project only, and development to a test project.
• Write down which experiments used which flags, so old charts remain understandable after the flag is deleted.

Monitoring tools show what your systems are doing. These integrations add why they changed.

What “observability” means

Observability is the practice of understanding what is happening inside a running system by looking at the signals it produces. Those signals include metrics (numbers over time, like requests per second), logs (text records of events) and traces (the path of one request through many services). Platforms like Datadog, New Relic, Dynatrace and Grafana collect and draw these signals.

The classic troubleshooting question is, “What changed?” Code deployments are usually marked on graphs already. Flag flips often are not, even though they can change behaviour just as dramatically. The observability integrations fix that gap.

What gets sent

When someone changes a flag in a connected environment, Flagsmith sends an event describing the change to the monitoring platform. On the monitoring side, that event can show up as a marker or annotation on dashboards, or as an entry in an event stream. Engineers looking at a sudden jump in errors can see, right on the graph, “Flag checkout-v2 turned on at 14:15.”

Setting up, in general terms

You usually enter the credentials the platform requires, such as an API key and the regional site address for your account, in the project’s integration settings. Some platforms need extra identifiers, like an application or account ID. After saving, flag changes in the connected environments begin to appear on the platform. Use a dedicated key with only the permissions it needs, so a leaked key cannot do much harm.

Error tracking tools

Some error-tracking products, such as Sentry, are also adding ways to record which flags were active when an error occurred. If your version of Flagsmith and your error tracker support this, it is very valuable: a crash report that says “this error only happens when the new search flag is on” saves hours of guessing. Check your dashboard for current support.

What these markers cannot do

A marker shows a flag changed. It does not prove the flag caused the problem. Correlation is a clue, not a verdict. The value is speed: the engineer checks the suspect first, flips the flag back if needed, and watches the graph recover. That is a far better first five minutes than digging through deployment history.

The cheapest incident-prevention tool is a team that knows what is changing.

Why chat notifications are worth setting up

In many companies the people affected by a flag change are not the people who made it. Support staff field questions from customers who suddenly see a new screen. Sales teams run demos that depend on a certain feature. Engineers on call get paged for behaviour they did not expect. A message in a shared channel prevents confusion before it starts.

The Slack integration posts a message when flags change in a connected environment. The message typically says which flag changed, in which environment, and who changed it. Because it lives in Slack, people can reply, ask questions and react right where the announcement appears.

How it is usually arranged

First, someone with the right permissions connects Flagsmith to your Slack workspace and approves the access it asks for. Then, for each environment you care about, you choose a channel. A sensible approach is a busy, low-priority channel for development and staging, and a calm, high-visibility channel for production. That way production alerts are never buried under test noise.

Getting the right amount of noise

Notifications are only useful if people read them. If the production channel receives fifty messages an hour from test automation, everyone will mute it, and then the one important message will be missed. This problem is called alert fatigue, and it is the most common way notification setups fail.

• Send production changes to a dedicated channel that only contains production changes.
• Keep automated test runs out of channels where humans are expected to pay attention.
• Invite the right readers: support, product, on-call engineering and release managers.
• Agree on a habit: if you flip a production flag, you can add a short reason in the thread.

A real-world habit worth copying

Many engineering teams that run frequent releases, including large web companies, treat production flag changes with the same visibility as deployments. A flag flip is a production change. Announcing it in a shared place, along with the reason, is the same discipline as writing a good deployment note, and it costs only a few seconds.

A flag with no owner and no reason is a future headache.

The hidden cost of old flags

Flags are meant to be temporary for most uses. You add one, roll out a feature, and then remove the flag and the old code path. In practice, flags are often forgotten. After a year, nobody remembers why “flag-checkout-test-3” exists or whether it is safe to delete. This pile-up is called flag debt, and it slowly makes code harder to understand and test.

Linking each flag to the work that created it is the best cure. When a flag points to a ticket or a pull request, anyone can open it and learn the story: who asked for it, what it was meant to prove, and whether the work is finished.

GitHub and issue trackers

Flagsmith can link a feature to external work items, most notably GitHub issues and pull requests. A pull request is a proposed code change that teammates review before it is merged into the main code. Linking it to a flag lets reviewers and product managers see at a glance which code goes with which switch.

Teams that use other issue trackers can often achieve the same result by placing the ticket link in the flag’s description or tags, or by using webhooks to talk to their tracker. The principle is the same everywhere: every flag should lead back to a human reason.

flowchart LR
  P["Plan: ticket created"] --> B["Build: code and flag added"]
  B --> R["Release: flag off in production"]
  R --> O["Rollout: small group then everyone"]
  O --> M["Measure: analytics and dashboards"]
  M --> C["Clean up: remove flag and old code"]
  C --> D["Done: ticket closed"]

Where integrations help in the life of a flag

When no ready-made integration exists, a webhook lets you build your own.

What a webhook is

A webhook is a message that one system sends automatically to a web address you provide whenever something interesting happens. You do not have to keep asking, “Has anything changed?” The system tells you. The technical name for this style is event-driven, and it is far more efficient than repeatedly checking for updates.

What you can do with them

Flagsmith can send webhooks when flags change in an environment, and can also send audit log events at the organisation level. Your receiving service gets a structured message, usually in JSON, which is a simple text format that programs can read easily. It includes information such as which flag changed and the new state.

Handling a webhook safely

flowchart TD
  A["Someone changes a flag"] --> B["Flagsmith records audit log entry"]
  B --> C["Flagsmith builds event payload"]
  C --> D["Signs payload when a secret is set"]
  D --> E["HTTPS POST to your endpoint"]
  E --> F{"Signature valid?"}
  F -->|"No"| G["Reject and log"]
  F -->|"Yes"| H["Queue the event"]
  H --> I["Return success quickly"]
  H --> J["Worker does the real work"]

The figure shows the recommended pattern. Anyone on the internet can send a message to your web address, so you must check that a message really came from Flagsmith. When you configure a shared secret, Flagsmith uses it to sign each message, and your receiver recomputes the signature to confirm it matches. A mismatched message is rejected.

After verification, do not do heavy work inside the request. Put the event on a queue, answer with a quick success reply, and let a background worker handle the real task. This keeps the sender from waiting and prevents timeouts.

Three rules for webhook receivers

• Be idempotent. That word means doing the same thing twice has the same result as doing it once. Messages can occasionally arrive more than once, so your handler should not break if it sees the same event again.
• Do not trust the order. Two quick changes can arrive in a different order than they happened. Use timestamps in the payload when order matters.
• Treat the message as a hint. If you need the exact current state, call Flagsmith directly and read it, instead of relying only on what the message said.

Clicking in a dashboard does not scale to dozens of projects. Automation does.

Why automate Flagsmith itself

For a small team, using the dashboard is fine. For a company with many services and environments, manual clicking becomes error-prone. Someone forgets to create a flag in staging. Someone creates “new-search” in one place and “newSearch” in another. Automation tools make setup repeatable, reviewable and consistent.

The common tools

OpenFeature: a common language for flags

OpenFeature is an open standard, hosted by the Cloud Native Computing Foundation, for how applications ask for feature flags. Instead of writing code that depends directly on one vendor’s library, your code talks to the standard interface, and a small plugin called a provider connects it to the actual service. Flagsmith offers providers for several languages.

The benefit is freedom. If you ever change flag services, your application code stays almost the same, and only the provider changes. For companies that worry about being locked into one vendor, this is a strong reason to adopt the standard from day one.

Moving from another tool

Teams switching from another feature flag product are often worried about rebuilding hundreds of flags by hand. Flagsmith provides import tooling for at least some other platforms, such as LaunchDarkly. Even when a ready-made importer is not available, the API makes it possible to script a migration. Always do a trial migration into a test project first and compare the results flag by flag.

Who may log in, and what may they change? Integrations with identity systems answer both questions.

Why this belongs in a guide about integrations

Not every integration moves flag data. Some connect Flagsmith to the systems that decide who your people are. A flag in production can affect every customer, so it matters who is allowed to change it. Connecting Flagsmith to your company’s identity system keeps access in line with your existing rules.

Single sign-on

Single sign-on, often shortened to SSO, lets people log in to many tools with one company account. It relies on standards such as SAML and OAuth or OpenID Connect. Flagsmith supports several login methods, including sign-in through well-known providers, and some options such as SAML are tied to higher-level plans. Check your plan to see what is available to you.

The security gain is large. When someone leaves the company, disabling their main account removes their access to Flagsmith at the same moment. There are no forgotten passwords on a spreadsheet and no former employee who can still flip a production flag.

Roles and permissions

After login, Flagsmith’s permission system decides what each person can do. A common design is to let many people view flags, a smaller group edit them in staging, and only a few approve changes in production. Production often deserves an extra guard such as a change request, where one person proposes a change and a second person approves it before it takes effect.

Think of two keys on a safe: both holders must turn their key. This slows down changes a little, which is exactly the point for high-risk environments.

Connecting identity to integrations

Permissions and integrations work together. For instance, a Slack message that says “Alex changed the payments flag” is only trustworthy if Alex’s account is a real, single person and not a shared login. Using SSO and personal accounts makes every audit entry, every chat notification and every dashboard marker meaningful, because they all point back to a real human.

The details differ by tool, but the shape of the work is the same every time.

No matter which integration you are adding, the same sequence keeps you safe. Follow it in a test project first. Doing a practice run costs ten minutes and saves you from sending test data to a real production dashboard.

A note on environments

The most common beginner mistake is connecting development and production to the same destination. Then a developer’s experiments pollute real charts, and you cannot tell real flag flips from test ones. Give each environment its own destination, or at least its own clearly different label.

Verifying that it really works

Do not assume success because the form saved without an error. Always run an end-to-end check: make a real, small change, then look in the destination tool. If nothing appears, check the key, the regional address, and whether the integration is enabled for the right environment, in that order. Many failures turn out to be a key pasted with an extra space or a key from the wrong region.

A look under the hood explains many surprises, such as small delays and why a failure rarely breaks your app.

Keep the hot path clean

The hot path is the part of the system that must be fast and must always work. For Flagsmith, that is answering “What are this user’s flags?” Your app is waiting, and a customer may be waiting behind it. Sending data to Slack or Datadog is not part of that answer, so good design moves it out of the way.

The usual approach is to do outbound work in the background. Flagsmith records the event, puts a job on a queue, and a separate worker process delivers it to the other service. If the other service is slow, only the background job waits. The user’s flag answer is already on its way.

What this means if you self-host

If you run Flagsmith yourself, make sure the background processing component is running, because outbound integrations depend on it. A common surprise is a new installation where flags work perfectly but no Slack messages or monitoring events ever appear, simply because the worker was never started. Your deployment guide for your version will list the exact component to run.

You also need egress, which means permission for your servers to make outgoing connections to the internet. In a locked-down company network, outgoing traffic is often blocked by default. Allow connections only to the specific addresses your integrations need, such as your monitoring provider’s address and Slack’s.

Timing and ordering

Because outbound delivery is asynchronous, which means it does not happen at the exact same instant as the change, you should expect small delays. Usually this is seconds, but it can be longer when a queue is busy or a destination is slow. Do not build anything that needs the notification to arrive within a precise fraction of a second.

Likewise, two changes made close together may be reported in a different order by some destinations. If the order truly matters, use timestamps carried in the event, or read the audit log, which is the reliable record.

Best effort, not guaranteed delivery

Treat integrations as best effort. That means Flagsmith will try to deliver, but your system should never depend on every single message arriving. If a critical action must happen when a flag changes, such as clearing a cache that protects correctness, add a safety net, for example a periodic refresh, in addition to the webhook.

Every bridge you build is also a door. Make sure each one has a lock.

Protect the credentials

Every integration needs a secret key. If someone steals the key to your monitoring account, they can send false data or read yours. Treat these keys like passwords. Store them in a secrets manager, not in documents or chat. Give each key the minimum permissions, rotate it on a schedule, and remove it immediately when the integration is retired or when a person who knew it leaves the team.

Know what leaves your walls

When you connect an analytics tool, you are sending information about your users to another company. Flag states and traits can reveal things, for example “this user is on the enterprise plan” or “this user is in the beta for a health feature.” Before connecting, ask what data would be sent, whether it includes anything personal, and whether your privacy policy and customer contracts allow it.

A good rule is data minimisation: send only what you truly need. Use internal user numbers instead of emails, and avoid placing sensitive traits on identities that will be forwarded to external tools.

Where your data lives

Different countries have different rules about where personal data may be stored. Laws such as the European Union’s GDPR place obligations on companies handling data of people in the EU. Many monitoring and analytics vendors offer regional versions of their service. If your rules require data to stay in a region, pick the matching regional address in the integration settings, and consider self-hosting Flagsmith if you need tighter control.

Secure the incoming side too

For webhooks, always use HTTPS so messages are encrypted in transit, always verify signatures, and never expose an endpoint that performs a powerful action without checking who is calling. Restrict the endpoint so it only does what it should, such as refreshing a cache, rather than something dangerous.

Integrations themselves need watching. Here is how to spot trouble and what to do about it.

How to know an integration is healthy

The simplest health check is an expected-event check. If your team flips flags regularly and a day passes with zero events in your monitoring tool or Slack channel, something may be broken. Some teams add a daily scheduled smoke-test flag change to prove the whole chain still works.

Also use the Flagsmith audit log as your reference. If the audit log shows a change that never reached the destination, the problem is in the bridge, not in the change itself.

Common failure scenarios

A calm troubleshooting order

When an integration seems broken, check from the source outward. First, did the change really happen and appear in the audit log? Second, is the integration enabled for that exact environment? Third, are the credentials and regional address correct? Fourth, can the Flagsmith server reach the destination across your network? Fifth, is the destination service itself healthy? Going in this order avoids jumping straight to blaming the vendor.

Plan for the bad day

Imagine the monitoring vendor has a long outage during the same hour your own system has trouble. You lose your flag markers exactly when you need them. The fallback is the Flagsmith audit log, which stays available as the authoritative history, plus a habit of asking in the team channel, “Did anyone change a flag?” Good processes work even when tools do not.

Proven shapes to copy, and common mistakes to avoid.

Patterns that work

Pros and cons of a rich integration setup

Common mistakes

Best practices in short

• Start with one or two integrations that solve a real, named problem, then add more.
• Give every integration an owner and a written purpose.
• Keep production alerts in their own quiet, trusted channel.
• Test after every key rotation or channel rename.
• Remove integrations and flags that are no longer used.
• Prefer the open OpenFeature standard in application code to keep your options open.

A made-up online shop shows how all the pieces fit together.

The following story is a hypothetical example, written to show how the integrations cooperate. Imagine an online shop called Maple Market. The team wants to launch a redesigned checkout page, but they are nervous because checkout is where money changes hands.

What made this smooth

Nothing in the story needed heroic effort. The team simply connected their tools in advance. Each integration did one small job: the ticket link gave context, Slack gave awareness, the monitoring marker gave diagnosis speed, analytics gave proof, and the webhook gave a quick cache refresh. The sum of these small jobs is the difference between a stressful launch and a boring one, and boring is exactly what you want from a launch.

Tools do not run themselves. Somebody has to own each one, or it slowly decays.

Why governance is not boring paperwork

Governance is a grown-up word for a simple idea: agreeing who is responsible for what. In a small team of three people, everybody knows everything, so nobody needs to write it down. In a company of three hundred, the same integration might be set up by someone who has since changed teams, using a key that nobody remembers creating. Six months later the key expires, the Slack channel goes quiet, and nobody notices until an incident.

Good governance does not need heavy meetings. It needs a short list, kept somewhere everyone can find it, that answers four questions for every integration: who owns it, why does it exist, where is its secret key stored, and what should happen if it stops working.

A simple ownership table

Here is an example of how a company might divide responsibility. The exact names will differ, but the pattern is useful: every row has a human owner, not a vague team mailbox.

Naming conventions that pay off

A naming convention is an agreed pattern for names. It sounds minor, but it affects every integration. When flag names appear as markers on a graph, as traits in analytics, and as lines in a Slack message, they are read by many people who did not create the flag. A flag named “checkout_new_payment_form” explains itself in all three places. A flag named “test2” does not.

• Start the name with the product area, such as checkout, search or profile.
• Describe what changes, not who asked for it.
• Use the same word separator everywhere, so searches work.
• Avoid names that contain personal or sensitive information, because the name may travel to outside tools.

Tags and descriptions

Flagsmith lets you attach tags and descriptions to flags. Use them to hold the owner’s team name, the ticket link and the planned removal date. Tags also make it easy to find every flag that belongs to one team, which is useful when you review old flags every quarter.

Reviewing changes before they happen

For production environments, many companies require a second person to approve changes. This does not mean distrust. It is the same reason pilots read checklists aloud: a second pair of eyes catches the slip that the first pair is blind to. The approval step also produces a clear record in the audit log, which in turn feeds every connected integration with a message that says, in effect, “this change was reviewed.”

Retiring an integration properly

Switching an integration off is not enough. A clean retirement has four steps. First, disable the integration in Flagsmith. Second, revoke the key in the other tool, so it cannot be used again. Third, remove the entry from your register. Fourth, tell the team in the usual channel, so nobody waits for messages that will never arrive. Skipping the second step is the most common mistake, and it leaves a live key lying around with no owner.

What works for one team of five can break down for fifty teams. Here is how to grow without chaos.

What changes as you grow

A small company often has one Flagsmith project, three environments and a handful of flags. A large company can have dozens of projects, each with its own environments, hundreds of flags per project, and many people changing them every day. The number of possible integration connections grows quickly, because each project and each environment may have its own settings.

At this size, three problems appear. The first is inconsistency: one team sends flag changes to a monitoring tool and another team does not, so incident responders cannot rely on markers being there. The second is noise: dozens of channels fill with messages that nobody reads. The third is sprawl: nobody knows how many keys exist or which ones are still in use.

Standardise the defaults

The best fix for inconsistency is a paved road, which means a standard, well-documented way of setting up integrations that most teams simply follow. For example, a platform team might decide that every production environment must send change events to the central monitoring platform, must post to a team channel, and must have at least two people with permission to approve changes. New projects start from that template, so good habits come free.

Automation helps here. If you describe your projects and environments in a tool like Terraform, you can copy the same pattern to every new project with almost no extra effort, and you can review every change like any other piece of code.

Reduce noise with sensible routing

Instead of sending everything everywhere, route messages by importance. Production changes go to a trusted channel with a small number of watchers. Staging changes go to a lower-priority channel. Development changes may not need a message at all, because the developer who made the change already knows. Likewise, in monitoring tools, show production markers on the main dashboards and keep test markers on test dashboards.

Use central and local ownership together

Most mature companies choose a middle path. The platform team supplies templates, rules and a register. Individual teams then use self-service to set up what they need, within those rules. This gives speed without losing control.

Watch the volume

Every flag change can trigger several outbound messages: one to chat, one to monitoring, perhaps one to a webhook. A script that changes two hundred flags at once could therefore create hundreds of messages in a few seconds. Destination services have limits on how fast they accept data, and a flood can lead to dropped events or temporary blocks. For bulk changes, spread the work over time, and warn the team in advance so a burst of messages does not cause alarm.

Measure the integrations themselves

At scale, you should measure how well your setup works. Useful questions include: how long does it usually take for a flag change to appear in the monitoring tool? How many integrations have failed in the last month? How many flags have no linked ticket? Even rough answers help you decide where to invest effort. If the answer to the last question is “most of them,” you already know your next improvement.

A simple decision guide for when you are not sure where to start.

Start from the question, not the tool

Beginners often start by asking, “Which integrations does Flagsmith have?” A more useful starting point is, “What problem am I trying to solve?” The tool follows from the answer. The guide below walks through the most common questions in order.

flowchart TD
  Q["What do you need?"] --> A{"Understand user behaviour?"}
  A -->|"Yes"| AN["Use an analytics integration"]
  A -->|"No"| B{"Explain graph changes?"}
  B -->|"Yes"| OB["Use an observability integration"]
  B -->|"No"| C{"Tell people quickly?"}
  C -->|"Yes"| SL["Use Slack notifications"]
  C -->|"No"| D{"Link to work items?"}
  D -->|"Yes"| GH["Link GitHub or tracker items"]
  D -->|"No"| WH["Use a webhook or the API"]

How to read the guide

Start at the top and answer each question honestly. If your main worry is understanding how users behave, an analytics integration is the right first step. If your worry is “why did that graph change?”, choose observability. If the real pain is that people are surprised by changes, tell them with chat notifications. If flags are piling up with no explanation, link them to work items. If none of these fits, the webhook and API are your general-purpose tools. You can, of course, answer yes to more than one question, and many teams end up using all of them over time.

Common situations and good first choices

Side-by-side comparison

The effort ratings here are rough, since your own situation will vary. Their purpose is to show a general pattern: the cheapest integrations deliver safety quickly, while the more flexible ones ask for more design and care.

Feature flags and the habits around them are not a fad. Large engineering teams have described them in public for years.

The examples below describe practices that these companies have talked about publicly in engineering blogs, conference talks or research papers. Details have surely changed over time, and none of these stories are claims about which specific tools each company connects. The aim is to show the habits that integrations support: gradual releases, visible changes, measurement and cleanup.

The common thread

Across all these stories, four habits repeat. First, separate shipping from releasing, so risky code can sit safely in production, switched off. Second, expand gradually, from staff to a few users to everyone. Third, watch the numbers while expanding, which requires change markers and dashboards. Fourth, learn from the results, which requires user-level data in analytics.

Notice that none of these habits is magic. Each one is supported by a small, boring piece of plumbing: a marker on a graph, a message in a channel, a trait in an analytics profile. Flagsmith’s integrations provide pieces of that plumbing, so a smaller team can follow the same habits without building everything from scratch.

Lessons for a smaller team

• You do not need a giant platform to copy the habits. A single Slack channel and one monitoring marker already cover two of the four.
• Start the gradual rollout habit with your very next feature. Even a ten percent step is a big improvement over switching on for everyone at once.
• Do not wait for the perfect experiment system. Record the flag state in analytics now, and the questions will arrive later.
• Treat cleanup as part of the work. Large companies who have written about feature flags often mention the cost of leaving old ones behind.

Two practical tools: what to do when something breaks, and how to roll out integrations without overwhelm.

Part one: using integrations during an incident

A runbook is a short, step-by-step guide that a tired person can follow at three in the morning. The runbook below shows how the integrations in this guide fit into a calm response when graphs go the wrong way.

Part two: a ninety-day plan

Adopting everything at once is a recipe for noise and confusion. A gradual plan spreads the effort and lets each step prove its worth before the next begins.

How to know the plan is working

After ninety days, check a few simple signs. During the last incident, did someone find the cause using a marker or a message, rather than guessing? Can a new teammate learn who owns each integration in under five minutes? Did the number of flags with no ticket go down? Did at least one experiment give an answer people trusted? If you can answer yes to most of these, your integrations are earning their keep.

Quick definitions of the words used in this guide, in one place.

An untested integration is a hope, not a safety net.

Why testing matters more here than you might think

Most software failures are loud. A page crashes, a user complains, an alarm rings. Integration failures are usually silent. When a key expires, nothing explodes. Messages simply stop arriving. You only find out when you need them, which is the worst possible moment. Because the failure is quiet, the only protection is to check on purpose, before you need the integration.

Testing an integration is not hard. It means making a small, harmless change and confirming the expected result appears in the other tool. What takes discipline is doing it regularly, and doing it after every event that could break the chain.

The smoke-test flag

A smoke-test flag is a flag that guards no real feature. Its only job is to be flipped so that the chain of integrations fires. Create one in every environment you care about, name it clearly, and put a note in its description that says “safe to flip, does nothing.” Anyone can then prove the chain works without worrying that they are changing real behaviour.

After flipping, check each destination in turn. Did Slack show the message in the right channel? Did the monitoring tool show the marker with the right time and name? Did the webhook receiver log the event? Did the analytics tool receive the flag state for a test user? Each check takes seconds, and together they cover your whole setup.

When to run a test

Testing webhook receivers

Webhook receivers deserve extra care because you build them yourself. Test four situations. First, a valid message, which should be accepted and processed. Second, a message with a wrong signature, which should be rejected. Third, the same message sent twice, which should not cause damage. Fourth, a message arriving while your own service is slow or down, to see how your system recovers. Many teams only test the first case and are surprised by the others in production.

Rehearse the failure, too

Beyond checking that things work, rehearse what happens when they do not. For example, ask the team: if our monitoring marker integration stopped working right now, how would we find out? Who would notice? Where would they look? Practising these questions in a calm meeting is far cheaper than discovering the answers during an incident.

Some teams even run a small “game day,” where they deliberately disable one integration in a test environment and see how long it takes someone to notice. The point is not to catch anyone out. The point is to find gaps in the alerts, the register and the runbook, while there is no pressure.

Keep a simple test record

A short log of when each integration was last tested, by whom and with what result is enough. It can be a shared note or a spreadsheet. The record has two uses. It reminds you when a test is overdue, and it gives you evidence during audits that your controls are checked, not just configured.

Setup is a day of work. Upkeep is a habit that lasts for years.

Things change around you

Even if you never touch your setup, the world around it moves. Vendors rename features, change their regional addresses, retire old keys, or adjust their limits. Your own company changes too: people join and leave, tools are replaced, and security rules tighten. An integration that was perfect a year ago may now be slightly out of date, and slightly out of date is exactly how silent failures begin.

A light maintenance routine

• Every week: run the smoke-test flag, and glance at the production channel for anything odd.
• Every month: check that every integration still has a named owner who is still at the company, and that keys have not been flagged for expiry.
• Every quarter: review the full register, remove unused integrations, and review who has permission to change them.
• Every year: rotate long-lived keys, review contracts and data locations with your privacy team, and revisit whether your set of integrations still matches your needs.

Staying informed about changes

Both Flagsmith and the tools you connect it to publish release notes and announcements. Assign someone to skim them. You are looking for three things: changes to how integrations are configured, retirement of old features or keys, and new capabilities that could replace something you built by hand. A few minutes of reading each month can save a weekend of emergency repair.

Upgrades if you self-host

Self-hosting gives you control, and with control comes responsibility. When you upgrade Flagsmith, read the upgrade notes carefully, test in a staging copy first, and then run your smoke tests against that copy before touching production. Pay particular attention to background workers and to environment settings, because integrations rely on both. After the production upgrade, test again.

Know when to simplify

Good maintenance sometimes means removing things. If an integration has not been used for months, if nobody reads a channel, or if two tools overlap, simplify. Fewer integrations mean fewer keys, fewer messages and fewer things that can quietly break. A setup that your whole team understands is more valuable than a clever one that only one person remembers.

Writing down what you know

Finally, write things down while they are fresh. A one-page note for each integration, covering what it does, how it was set up, how to test it and how to switch it off, turns hard-won knowledge into something the next person can use. Documentation is a gift to your future teammates, and very often, to your future self.

Myths and misunderstandings worth clearing up

Over the years, a handful of wrong beliefs about integrations cause the same problems again and again. Knowing them in advance saves time.

Each of these myths has the same root: treating a connection as a finished product rather than as a living part of your system. Once you accept that integrations need ownership, tests and small amounts of regular care, most of the common failures simply stop happening. Start small, prove each step with a real test, write down who owns what, and review the setup on a calendar rather than on a whim. Teams that follow this rhythm rarely have dramatic integration failures, because small problems are noticed and fixed while they are still small, long before they can interfere with a launch, an experiment or an incident response. The reward is quiet, steady confidence that when something changes in production, the right people will know, the right graphs will show it, and the right data will explain what it did.

Quick answers to the questions beginners ask most often.

The whole guide on one page.