Skip to content

Feature Flags

A Feature Flag (also called a feature toggle or feature switch) is a named value that your application can read to decide what to show users or how to behave. It's the core building block of everything in FlagPal.

Think of a feature flag as a variable that you can change without redeploying your app — and that you can control from the FlagPal dashboard.

A feature flag can be anything you want it to be: a simple on/off switch (beta_program = true) or a user property (country = US)

This is the core building block of everything in FlagPal: it combines your application's features together with your user properties, enabling you to build powerful flows with little effort.

A Simple Analogy

Imagine your app is a house. Feature flags are the light switches:

  • Some switches are just on/off (show this feature or hide it)
  • Some switches have a dimmer (control how much of something to show)
  • You can flip a switch from FlagPal's dashboard without going into the house and rewiring anything

What Can Feature Flags Do?

Here are real-world examples of how teams use feature flags:

Use Case Example Flag
Hide unfinished features show_new_profile_page = false
Gradual rollout enable_payments_v2 = true (for 10% of users via Experiences)
A/B testing checkout_layout = "classic" or "redesigned" (via Experiments)
Kill switch maintenance_mode = true (shows maintenance instantly without deployment)
Feature tiers max_team_members = 5 (free) or 50 (paid)

Feature Flag Types

Not all flags are simple on/off switches. FlagPal supports several types of feature flags:

Boolean (True/False)

The most common type. The flag is either true or false.

Example: show_new_dashboard = true

Use this for: showing/hiding features, enabling/disabling functionality.

String (Text)

The flag contains a text value.

Example: theme_color = "blue" or "green" or "dark"

Use this for: selecting between named options, theme values, layout variants.

Integer (Whole Number)

The flag contains a whole number.

Example: max_file_uploads = 10

Use this for: limits, counts, numeric configurations.

Array (List)

The flag contains a list of values.

Example: available_plans = ["solo", "team", "enterprise"]

Use this for: rendering dynamic lists.

Date

The flag contains a date value.

Example: user_registration_date = 2024-06-01

Use this for: time-based feature availability.

Feature Flag Rules

As an optional feature, you can define a list of rules for each Feature Flag. For example, you may want to define allowed values for the flag. This prevents typos and makes it easier to configure flags in Experiences and Experiments. When your app sends values for this flag, they it can only use these predefined values.

For example:

  • The country flag may enforce a list of all available countries ("DE", "US", "CA", "AU", etc.)
  • The discount_percentage flag may enforce a range of positive integer values (from 0 to 100)
  • For a flag named checkout_style, you might define allowed values as "classic", "minimal", "modern"

You don't have to set these rules. They are only used for validation purposes to ensure your flags are configured correctly. You can enforce this validation in your application itself.

Creating Feature Flags

To create a feature flag, navigate to Features in the sidebar and click New Feature. You'll need to provide:

  • Name — a unique identifier for the flag (e.g., show_new_checkout)
  • Description — what this flag controls (optional but helpful for your team)
  • Type — the kind of value this flag holds (Boolean, String, Integer, Array, or Date)

Step-by-step guide: Creating a Feature Flag →

Flag names can't be changed after creation. Choose your flag names carefully — once a flag is created, its name is permanent. Use clear, descriptive names that your whole team will understand.

The Lifecycle of a Feature Flag

Here's how a feature flag typically gets used:

  1. Define the flag in FlagPal (give it a name and type)
  2. Integrate it into your app's code (your developer reads the flag value via the API)
  3. Use it in an Experience to roll out the feature to users
  4. Use it in an Experiment to test different values with different user groups
  5. Retire the flag once the feature is fully rolled out and stable. You may delete it or agree to keep it for historical purposes.

Best Practices

  • Use clear names — show_new_checkout_button is better than flag_1 or checkout
  • Add descriptions — future you (and your teammates) will thank you
  • Clean up old flags — remove flags for features that are fully launched and no longer need toggling
  • One concern per flag — don't try to use one flag to control multiple unrelated features
  • Experiences — use flags to control feature rollouts
  • Experiments — use flags to run A/B tests
  • Actors — the users who receive flag values