Unleash Portal — Feature Deep Study

The most common flag type. Controls whether a feature is released to users. Simple on/off per environment. Used for trunk-based development — merge your code behind a flag, release when ready without a new deployment.

• Use case: "Show the new checkout page only to users in production gradually."
• Default off → turn on when ready to release → remove flag once stable.
• Supports all activation strategies (gradual rollout, user IDs, etc.)

Used for A/B testing and multivariate experiments. Uses the Variants system to assign users to different groups and track metrics per variant. Designed to be short-lived.

• Use case: "Show button color A to 50% of users, color B to 50%."
• Variant weights determine distribution (must sum to 100%).
• Returns variant name + optional payload to your SDK. You track metrics externally.

Controls operational behavior of the system, not user-facing features. Long-lived. Used for circuit breakers, maintenance modes, and system configuration.

• Use case: "Switch from old payment provider to new one without deployment."
• "Enable maintenance mode for database migration window."
• Often permanent — lives in the codebase for months or years.

A safety valve — normally enabled, disabled only in emergency. Inverts the mental model: default is ON, you disable it when something goes wrong. Critical for production safety.

• Use case: "If the recommendations engine fails, disable it — show fallback UI instantly."
• Zero-downtime incident response: disable a broken feature without deploying.
• Combined with Signals & Actions (Enterprise), this becomes automatic.

Controls access to features based on user roles, plan tiers, or entitlements. Long-lived. The flag IS the permission check.

• Use case: "Only show the export CSV button to users on the Pro plan."
• Avoids hardcoding plan checks in application code.
• Change entitlements without deployment — update the strategy in Unleash Portal.

Simplest strategy — flag is on for everyone or off for everyone. No targeting. The toggle itself is the switch.

Roll out to a percentage of users. Uses consistent hashing (MurmurHash) so the same user always gets the same result. Set 0%→10%→50%→100% gradually. Configure which field is used as the stickiness key.

• Stickiness options: default (userId, sessionId, or random), userId, sessionId, or any custom context field.
• Grouping: Multiple flags sharing the same groupId get consistent bucketing — if user sees flag A, they see flag B too.

Enable the flag only for specific user IDs. Perfect for beta testers, internal team testing, canary users. Add/remove IDs without deployment.

Enable for specific IP addresses. Useful for office IP allowlisting, data center ranges, or development machines.

Enable only on specific server hostnames. Useful for canary server deployments or enabling a feature on specific pods in Kubernetes.

Define your own strategy with custom parameters. The Unleash Portal stores the strategy definition; your SDK implements the evaluation logic. You register the custom strategy with the SDK client.

• Example: "AccountPlan" strategy — takes a "plan" parameter, enables if user's plan matches.
• Strategy definition (schema) stored in Unleash. Evaluation logic in your SDK.

Constraints are AND conditions added on top of any strategy. They filter further. Example: gradual rollout to 50% AND only if user is in "premium" segment AND app version >= "2.0.0".

• Operators: IN, NOT_IN, STR_STARTS_WITH, STR_ENDS_WITH, STR_CONTAINS, NUM_EQ, NUM_GT, NUM_LT, DATE_AFTER, DATE_BEFORE, SEMVER_EQ, SEMVER_GT, SEMVER_LT
• Can constrain on any context field: userId, sessionId, remoteAddress, properties.*, appVersion, environment, etc.
• Inverted constraints also supported (NOT logic)

Variants extend a flag beyond on/off. Each enabled user gets assigned one variant based on weighted distribution. You use this for A/B/C/D testing. Each variant can carry a payload (JSON, string, CSV, number) passed to the application.

• Weight: Each variant gets a weight (total must = 1000 = 100%). E.g., variant A = 500, variant B = 500 = 50/50 split.
• Payload: Optional data sent with the variant. E.g., {"color": "blue", "size": "large"} for a button test.
• Stickiness: Same user always gets the same variant. Uses same hashing as gradual rollout.
• Override: Force specific users into a specific variant (for QA testing).
• Disabled variant: What users get when the flag is off — you define this to avoid null checks in code.

Each flag has independent on/off state and strategy configuration per environment. Turning on a flag in staging does NOT affect production. Environments also control which tokens can read which flags.

• A flag can be ON in development but OFF in production.
• Strategies can differ per environment (100% rollout in dev, 5% in prod).
• Client API tokens are scoped to one environment.

Projects group related feature flags together. Each project has its own flags, members (in Enterprise), and segments. Typical grouping: one project per product team or microservice.

• Default project is "Default" — flags live here unless you create projects.
• Flags are scoped to a project — cannot be shared across projects (by design).
• Members assigned per project in Enterprise. In OSS, access is global only.

Three fixed roles available in OSS:

Default authentication. Users have Unleash accounts with email and password. Suitable for small teams or self-hosted setups where SSO is not needed.

Connect Unleash to any OIDC-compatible Identity Provider. Users log in through your IdP. Available in OSS.

• Providers supported: Google Workspace, GitHub, Azure Active Directory (OIDC mode), Okta (OIDC mode), Auth0, Keycloak, AWS Cognito, and any OIDC-compliant IdP.
• Config: Issuer URL, Client ID, Client Secret — standard OIDC discovery.
• Auto-create users: Option to auto-create users in Unleash on first OIDC login.
• Role mapping: In Enterprise, map IdP groups to Unleash roles automatically.

Define segments at the project level. A segment is a named set of constraints that can be attached to any strategy within that project. Changes to the segment automatically apply to all flags using it.

• Example segment "Beta Users": userId IN [123, 456, 789] AND properties.betaEnrolled = "true"
• Attach this segment to 20 flags — update one segment, all 20 flags update.
• OSS limit: Segments are scoped to a single project. Cannot be shared with other projects.

Every SDK call to evaluate a flag sends back impression data. OSS aggregates and displays this in the Portal. You see per-flag request counts (yes count = flag was enabled, no count = flag was disabled) per environment.

• Last 1 hour and last 24 hours of flag evaluation counts.
• Per-application breakdown (which app is calling which flag).
• Charts in the flag detail page.
• Metrics reset every hour (rolling window, not historical).

Fire an HTTP POST to any URL when Unleash events occur. Use for custom automation, audit pipelines, or integration with any system.

• Events: feature-created, feature-updated, feature-enabled, feature-archived, strategy-created, etc.
• Custom headers and payload templates supported.

Built-in addon integrations. Post flag change notifications to Slack channels or Teams rooms. Send feature flag events to Datadog as events for correlation with metrics.

Used by server-side SDKs to poll the Unleash server for flag configurations. Scoped to a specific project and environment. Read-only — cannot make changes via Admin API.

Safe for use in browser-side / mobile applications. Unlike client tokens, frontend tokens do not expose all flag configurations — they return evaluated flag results only for a given context. Works with Unleash Proxy and Unleash Edge.

Full access Admin API tokens. Can read and write everything. Used for CI/CD scripts, admin automation. Should never be used in application SDKs. Treat like root credentials.

User-specific tokens for Admin API access. Have the same permissions as the user who created them. Users can create and revoke their own PATs. Useful for personal scripts and developer tooling.

The Playground lets you test flag evaluation without writing any code. You provide a context (userId, sessionId, remoteAddress, properties) and the Playground shows you which flags would be enabled for that context and why.

• Select any environment to test against.
• See results for all flags at once, or filter to a specific flag.
• Explanation view: For each flag, shows which strategy matched, which constraints passed/failed, and what variant was assigned.
• Critical for debugging "why is this flag on/off for this user?" without looking at code.

Unleash logs all admin actions as events. You can view the event history in the Portal. OSS keeps a functional event log accessible via the UI and Admin API.

• Events: feature created, enabled, disabled, strategy changed, archived, user added, token created, etc.
• Shows who made the change, when, and what changed.
• OSS limit: UI shows recent events (limited history). No filtering, export, or compliance-grade retention policies.