Skip to Content
Product guidesFeature flags

Feature flags

Feature flags deliver typed configuration to target apps without making application startup depend on a network request.

Engage feature flag inventory with key, type, lifecycle, rollout, target apps, and evaluation metrics
Feature flag inventory exposes the published contract and rollout state that SDK reads depend on.

Value types

Flags are boolean, string, number, or JSON. Choose the type at creation and provide a safe default. Client code must also provide a local fallback of the same semantic type.

Targeting and variants

A flag configuration contains:

  • structured audience expression;
  • target app IDs;
  • default value;
  • variants with stable keys, typed values, and allocation percentages;
  • optional conversion event name.

Allocation is deterministic for an eligible subject. A user should not jump variants on every read. The published revision and assigned variant are included in exposure/experiment analysis.

Draft and publish

Flags are draft, active, or archived. Editing an active flag creates unpublished changes while runtime continues using publishedConfiguration and publishedRevision. Publish atomically activates the new snapshot.

An active experiment can constrain lifecycle changes. Avoid editing allocation, conversion semantics, or audience during an analysis window unless the experiment design explicitly allows it.

Engage feature flag editor with stable key, typed default, variants, targeting rules, rollout, apps, and publication controls
The flag editor treats type, default value, rules, variants, allocation, and app scope as one versioned evaluation contract.

Client evaluation

SDKs synchronize active app-scoped flags and persist them locally. Android/iOS evaluate against the local snapshot; Flutter crosses its native bridge but does not wait for a network fetch. Always provide a safe fallback. See Preferences, flags, and privacy.

Rollout checklist

  1. Define default behavior that is safe without Engage.
  2. Select only apps containing compatible client code.
  3. Preview audience and allocation.
  4. Publish before expecting clients to receive the revision.
  5. Track a stable conversion event if measuring impact.
  6. Monitor exposure and app-version distribution.
  7. Archive only after old app versions no longer require the flag.
Build automationsPreferences