Create Flags and variations

Discover FlowSync example at the end of the article.

Creating flags and variations is a foundational step in modern feature experimentation and rollout. Feature flags allow you to control the visibility and behavior of features in your application without deploying new code. By defining variations, you can test different versions of a feature or configuration, safely experiment in production, and progressively deliver new experiences to targeted user segments.

Prerequisites

Before you begin, make sure you:

  • Have the necessary permissions to create and manage campaigns in the FE&R platform.

  • Have installed the FE&R SDK or set up the Decision API in your application, website, or device. You’ll need your environmentId for this step. For guidance, see the Getting Started with Flagship documentation (recommended for developers and technical users).

Main Steps to Create Flags and Variations

Follow these steps to launch your first experimentation or rollout. For detailed step-by-step instructions, refer to our How-to articles.

1

Create a Flag

  1. Navigate to the Flags section in the Feature Experimentation menu.

  2. Click Create Flag and fill in the required information (name, type: Boolean, String, or Integer, and description).

  3. Flags act as feature toggles or configuration keys that your application will read at runtime. Choose the flag type based on the kind of value you want to control (e.g., on/off, color, text).

2
  • Context keys allow you to target specific user segments or conditions (e.g., location, device, user behavior).

  • Go to Feature Experimentation > Context Keys and create keys as needed for your experiment targeting

3

Create a variation

  • Create a campaign:

    • Feature Experimentations > Campaigns > Create campaigns

    • Choose your campaign type:

      • AB Test, or

      • Feature Toggling, or

      • Personalization

    • Fill the campaign informations

    • Select your flag.

4

Set trafic allocation (optionnal)

Traffic allocation is only due for experimentations.

Decide what percentage of your users will see each variation. This ensures a fair and measurable experiment.

Example: Ren & Jess Create Their First Feature Flag

To run their onboarding experiment, Ren and Jess need a simple Boolean flag to control whether users see the updated onboarding step.

1. Creating the Flag Jess goes to Feature Experimentation > Flags and clicks Create Flag. She names it onboarding_step_v2_enabled, selects Boolean, and adds this description:

“Enables the new version of step 2 in the onboarding flow.”

This gives Jess full control over activating the new version without redeploying code.

2. Adding a Context Key Because Ren wants to target new users first, Jess creates a new context key:

  • Key: is_new_user

  • Type: Boolean

  • Description: Indicates whether the user created an account within the last 7 days.

When initializing the SDK, Jess passes this value for each visitor based on backend logic.

3. Creating Variations Ren needs to create variations and define how these variations will be delivered to users inside a Feature Toggle campaign:

  • Variation A (Default): false → users see the current onboarding step

  • Variation B: true → users see the new onboarding step Jess built

To control when each variation is applied, Ren goes to Feature Experimentation > Campaigns and creates a new campaign of type Feature Toggle using the flag onboarding_step_v2_enabled.

Inside the campaign, Ren manually creates two scenarios:

  • Scenario 1: New Users

    • Targeting rule: is_new_user = true

    • Flag value: true → New users will see the updated onboarding step.

  • Scenario 2: All Other Users

    • Targeting rule: none (default audience)

    • Flag value: false → All remaining users stay on the existing onboarding step.

This setup gives Ren full control over who receives the new experience, while keeping the rollout safe and incremental. Jess simply retrieves the flag value through the SDK: no additional deployment needed.

4. Setting Traffic Allocation In this campaign, as it's a feature flagging initiative, traffic allocation is unnecessary.

5. Ready for Activation Once the flag is saved, Jess fetches it through the SDK in the onboarding code. Ren can now activate, pause, or progressively increase exposure, all without Jess pushing new deployments.

Last updated

Was this helpful?