📄️ Actions
Plan 5.11+ in BETA
📄️ Activation Strategies
It is powerful to be able to turn a feature on and off instantaneously, without redeploying the application. Activation strategies let you enable a feature only for a specified audience. Different strategies use different parameters. Predefined strategies are bundled with Unleash. The recommended strategy is the gradual rollout strategy with 100% rollout, which basically means that the feature should be enabled to everyone.
📄️ API Tokens and Client Keys
For Unleash to be of any use, it requires at least a server and a consuming client. More advanced use cases may call for multiple clients, automated feature flag updates, the Unleash proxy and Unleash proxy clients, and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind.
📄️ Applications
Version: 5.11+
📄️ Archived Flags
You can archive a feature flag when it is not needed anymore. You do this by clicking the "Archive" button on the feature flag details view. When you archive a feature flag, it will no longer be available to Client SDKs.
📄️ Banners
Plan 5.7+
📄️ Change Requests
Plan 4.19+
📄️ Command Menu
Version: 6.2+
📄️ Custom Activation Strategies
This document is a reference for custom activation strategies. If you're looking for a guide on how to use them, see the how to use custom strategies guide.
📄️ Dependent Features
Plan 5.7+
📄️ Environments
Version: 4.3+
📄️ Events
Overview
📄️ Feature Flag Naming Patterns
Plan 5.7+
📄️ Feature Lifecycle
Version: 6.2+
📄️ Feature Flags
Feature flags are the central concept that we built Unleash around. In Unleash, feature flags are organized within projects. Feature flags can have different activation strategies for each of their project's environments, and can also be given variants to facilitate A/B testing.
📄️ Feature Flag Types
Version: 3.5+
📄️ Feature Flag Variants (deprecated)
Feature Flag Variants at the environment level are deprecated in favor of the strategy variants.
📄️ Front-end API access
Version: 4.18+
📄️ Impression Data
Version: 4.7+. Requires SDK compatibility.
📄️ Insights
Plan 6.0+
📄️ Login History
Plan 4.22+
📄️ Maintenance Mode
Version: 4.22+
📄️ Network View
Plan 4.21+
📄️ Notifications
Plan 4.22+
📄️ Playground
Version: 4.14+
📄️ Public Invite Links
Public invite links let you invite team members to your Unleash instance. Any user with an invite link can sign up to Unleash instance that created the link. The user will get the viewer role (refer to the predefined roles_ section of the RBAC document for more information on roles).
📄️ Projects
Overview
📄️ Project Collaboration Mode
Plan 4.22+
📄️ Provisioning
Plan 6.1+
📄️ Resource Limits
Version: 6.2+
📄️ Role-based Access control
Version: 4.0+
📄️ Search with filters/operators
Version: 5.9+
📄️ Segments
Version: 4.13+ for Pro and Enterprise.
📄️ Service Accounts
Plan 4.21+
📄️ Signals
Plan 5.11+ in BETA
📄️ Single Sign-On
Plan: Enterprise
📄️ Stickiness
Stickiness is how Unleash guarantees that the same user gets the same features every time. Stickiness is useful in any scenario where you want to either show a feature to only a subset of users or give users a variant of a feature.
📄️ Strategy Constraints
Version: 4.16+
📄️ Strategy Variants
Version: 5.4+
📄️ Tags
Version: 3.11+
📄️ Technical Debt
At Unleash we care deeply about code quality. Technical debt creeps up over time and slowly builds to the point where it really starts to hurt. At that point it's too late. Feature flags that have outlived their feature and are not cleaned up represent technical debt that you should remove from your code.
📄️ Unleash Context
The Unleash Context contains information relating to the current feature flag request. Unleash uses this context to evaluate activation strategies and strategy constraints and to calculate flag stickiness. The Unleash Context is an important feature of all the Unleash client SDKs.