Create Flags and variations
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
environmentIdfor this step. For guidance, see the Getting Started with Flagship documentation (recommended for developers and technical users).
Main Steps to Create Flags and Variations
Create a Flag
Navigate to the Flags section in the Feature Experimentation menu.
Click Create Flag and fill in the required information (name, type: Boolean, String, or Integer, and description).
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).
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_userType: 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 stepVariation 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 = trueFlag 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?

