Creating feature flags

Last updated:

|Edit this page

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

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:

  1. Slower feature flag response: Enabling this option introduces additional checks, which can slow down the response time when fetching feature flags.
  2. Incompatible with local evaluation: It is necessary to perform the additional checks on the PostHog servers.
  3. 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

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.

Questions?

  • Harshini
    12 days ago

    Feature Flags - Payload

    Hi

    I have used 2 variants in my feature flag and given 2 different payloads for each variant.

    When I try to pull the value in my FE code, it only throws one variant value for both variant while i test it through toolbar.

    const posthogPayload: any = useFeatureFlagPayload('membership-benefits-cta');

  • Giorgos
    4 months ago

    DistinctID not saved in user

    I am doing:

    const pinterestEnabled = await isFeatureEnabled('pinterest', '8ce04f11-aaa7-4326-bf36-e98a907807df');

    I was expecting to see a user with DistinctID = '8ce04f11-aaa7-4326-bf36-e98a907807df', but I do see a user that has IDs 8ce04f11-aaa7-4326-bf36-e98a907807df and Creator Event ID 0193baa2-282b-7726-99f3-e412b38473fb. I have to manually add the distinct_id property

  • Giorgos
    4 months ago

    only Creator Event ID is captured

    I am doing:

    const pinterestEnabled = await isFeatureEnabled('pinterest', '8ce04f11-aaa7-4326-bf36-e98a907807df');

    I was expecting to see a user with DistinctID = '8ce04f11-aaa7-4326-bf36-e98a907807df', but I do see a user that has IDs 8ce04f11-aaa7-4326-bf36-e98a907807df and Creator Event ID 0193baa2-282b-7726-99f3-e412b38473fb. I have to manually add the distinct_id property

  • Nathan
    5 months ago

    Feature Flags as Code

    Hi folks, Found out about PostHog yesterday and really like the whole vibe. I'm used to managing feature flags via Terraform. They feel like infrastructure to me so managing them via Git like the rest of our stack feels appropriate, especially to replicate changes across multiple environments. I see you have an API that could be leveraged to a similar effect but I'm curious about how existing users tend to approach this. Does everyone just manage them via the UI or write what amounts to a custom Terraform provider?

  • Livio
    6 months ago

    Mix release conditions based on User & Groups

    We ❤️ the release conditions within the feature flags settings. Though one thing that is missing for us is the option to setup e.g. 2 release conditions where one condition checks for a certain property on the group and another conditions checks on the user level.

    As far as I can tell it's only possible to set the "Match by" Dropdown for all release conditions of a feature flag?

    • Steven(he/him)
      5 months ago

      Hey @livio/28955 , Yes, thanks for clarifying. That is a challenge since groups properties are not stored in the person profiles. (For more on that topic, see How are cohorts different from groups? )

      You can filter by cohorts when Match by is set to User(s).

      Alternatively, you could start capturing a custom person property which identifies each person profile as associated with a particular organization, and then you could use that person property in filters for release conditions while the Match by menu is set to User(s).

  • MOHAMMED
    6 months ago

    Question about release conditions

    Hello everyone,

    I have one question regarding feature flag release condition, so far when try to add new condition, there is only specific properties can choose! is there possibility to add our properties? like "phone number", "email" , "agent group", etc.

    That mean, I don't want to stuck with only exist condition properties to evaluate the condition.

    Plus, I have notice these properties are different between US and Europe region (US region not have person properties)

    please any help on that?

  • Will
    7 months ago

    Existing user reassignment when rollout percentage is changed

    If I change the rollout percentages for a multivariate flag, what happens to existing users? For example, if I have flag_value_1, flag_value_2, flag_value_3 at 40/40/20, respectively, then I change the % to 40/60/0, what will happen?

    1. Existing users keep their assignments, new users are assigned according to the new distribution
    2. The entire distribution is reset, so now all users follow the new 40/60
    3. The 20% from flag_value_3 are all changed to flag_value_2
    4. Other

    Assuming it's #1, but I can't a conclusive answer in the docs. Thank you!

    • Juraj
      6 months ago

      Hey Will,

      Option 3. is correct - changing rollout does affect variant assignment and this is exactly what would happen in your case.

      Cheers, Juraj

  • Will
    7 months ago

    What happens when the rollout percentages are changed on a multivariate flag

    If I change the rollout percentages for a multivariate flag, what happens to existing users? For example, if I have flag_value_1, flag_value_2, flag_value_3 at 40/40/20, respectively, then I change the % to 40/60/0, what will happen?

    1. Existing users keep their assignments, new users are assigned according to the new distribution
    2. The entire distribution is reset, so now all users follow the new 40/60
    3. The 20% from flag_value_3 are all changed to flag_value_2
    4. Other

    Assuming it's #1, but I can't any documentation. Thank you!

  • Daniel
    9 months ago

    Release condition to (de)activate for version greater/smaller than a.b.c

    Hej, we're having a use case in which we want to (de)activate certain feature toggles based on the (semantic) version of a client application. The UI allows us to select concrete versions and use a limited amount of comparison operators, > and < not being one of them. To address this, we have already added the posthog-semver-flattener plugin to the data pipeline. However, while the attributes $app_version__major, $app_version__minor and $app_version__patch are now available in events, they seem not be available for Persons. Therefore, I also can't select them in release conditions to e.g. toggle on a feature toggle for every user having a client >= 1.4.0. What is the "posthog way" of covering this use case which I don't seem to grasp?

    • Red
      4 months ago

      +1, very much need this too

  • Richard
    a year ago

    Feature flag not working

    We have an issue where the feature flag seems to be intermittently applied. In the example below, when refreshing the page for the same user, sometimes the default text will appear, and other times the test text will appear. Are we missing something?

    <div>
    {window.posthog &&
    window.posthog.isFeatureEnabled('onboarding-text-experiment')
    ? 'Show this text if flag enabled.'
    : 'show default text'}
    </div>
  • Isaac
    a year ago

    Inquiry

    I am new on the platform, read some article on your feature flag. But I need to understand in details how it is used in managing an application hosted on different environments.

    I would like to meet with the support team here please.

  • Isaac
    a year ago

    Inquiry About the Use of Feature Flag

    Hello, My name Isaac Nwankwo from helium health company, My question is this. Does the feature flag work for on-prem or offline clients. We have some of our clients product hosted on the cloud, while some deployment onprem, I need to know more how we can utilize this feature with our product.

    • Neil
      a year ago

      Hi Isaac,

      Dynamic flags that need to update in real time wouldn't work with offline clients. In this case, you'd need to either permanently set flags to a certain value on installation, or keep them all disabled.

      For on-prem, if you can create a connection to PostHog's servers, they'll work as usual. If not, they'll be like the offline case.

      Does this make sense?

    • Isaac
      Authora year ago

      Yes it does

  • fabienne
    a year ago

    How to copy / paste multiple values in a feature flag condition

    Hello,

    I am trying to create a feature flag that would allow multiple pasted values in the user id. How can I copy / paste a list of values into that field without having to enter them one by one? thanks a lot !

    Screenshot 2024-02-09 at 12.25.55.png

    • Neil
      a year agoSolution

      Hi Fabienne,

      You should be able to do this by pasting a comma separated list of values. In this case if you paste the following in, it should work:

      abc,def,ghi

Was this page useful?

Next article

Adding feature flag code

Once you've created your feature flag in PostHog, the next step is to add your code:

Read next article

PostHog.com doesn't use third party cookies - only a single in-house cookie.

No data is sent to a third party.

Ursula von der Leyen, President of the European Commission