To create a new feature flag, navigate to the feature flags tab in your PostHog app, where you should see a 'Create feature flag' button that we'll click.
This presents you with a form where you can complete the details of your new flag:
![How to create a feature flag in PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/features/feature-flags/create-new-feature-flag-light-mode.png)
![How to create a feature flag in PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/features/feature-flags/create-new-feature-flag-dark-mode.png)
Here's a breakdown of each field in the form:
Key
This is the name of the key you use in your code to evaluate the feature flag.
Description and tags
Metadata to describe and share information about your feature flag in the PostHog app.
Enable feature flag
This determines whether your flag is enabled. Disabled flags return undefined
or null
.
Persisting feature flags across authentication steps
Note: This is only relevant if your feature flag is shown to both logged out AND logged in users.
Feature flag values are calculated based on a user's properties. Since it's possible for a user to have different properties before and after login, they may receive different feature flag values before and after logging in.
By enabling the option to persist feature flags across authentication, you ensure that the flag value remains the same.
In our experience, the tradeoffs to enabling this are not worthwhile for the majority of our users. They include:
- Slower feature flag response: Enabling this option introduces additional checks, which can slow down the response time when fetching feature flags.
- Incompatible with local evaluation: It is necessary to perform the additional checks on the PostHog servers.
- Incompatible with bootstrapping: Bootstrapping relies on local evaluation, which cannot correctly calculate persistent flag values.
Served value
There are two types of feature flags:
1. Boolean flags.
These return true
or false
.
2. Multiple variant flags (multivariate flags).
Instead of returning true or false, multivariate flags return a key – for example, control
or test
.
You can choose the rollout percentage for each variant key, where each is given a specific percentage of the total audience. Users will then be randomly assigned to each variant based on these percentages.
Payloads
A payload is an additional piece of information sent to your app when a flag is matched for a user. The returned value can be any valid JSON type (object, array, number, string, boolean, or null).
They enable you to configure functionality related to your flag inside PostHog, instead of having to make code changes or redeploy your app.
Note: Payloads are only available in our JavaScript web, Node, Python, Ruby, and React libraries.
Release conditions
This specifies the conditions a user must meet to access the feature flag and receive a value.
Percentage rollouts are available for all flags. More options depend on your PostHog setup:
If GeoIP is enabled, you can target based on geographic location.
If you capture identified events, you can target based on person properties and cohorts.
If you enabled group analytics, you can target based on group properties.
![Feature flags release conditions](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/features/feature-flags/release-conditions-light-mode.png)
![Feature flags release conditions](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/features/feature-flags/release-conditions-dark-mode.png)
Can I migrate my feature flags from another tool? If you can pull feature flag data from them, you can use our API to migrate them. We even wrote guides for doing this with LaunchDarkly and Statsig.