Understanding feature management

Feature flags are conditional statements in your code that determine whether a piece of functionality runs. When a flag is toggled on, the feature is enabled. When toggled off, the behavior is hidden or skipped.

Think of feature flags as switches in your application code. Just as a light switch controls whether electricity flows to a bulb, a feature flag controls whether code execution flows to a particular feature. The critical difference is that you can flip these switches remotely without deploying new code.

Feature flags support three data types:

The fundamental benefit is decoupling deployment from release. You can deploy code containing inactive features, then activate them independently through flag configuration. This separation eliminates the traditional risk where every deployment potentially introduces user-visible changes.

Basic feature flags become powerful when combined with enterprise-grade management capabilities. CloudBees Unify feature management provides the infrastructure and tooling needed for safe, controlled feature delivery at scale.

Progressive delivery enables incremental rollouts to increasingly larger user segments. Rather than enabling features for all users simultaneously, you can start with internal teams, expand to beta users, then gradually reach your entire audience. This approach reduces blast radius when issues occur and provides early feedback opportunities.

User segmentation and targeting allows precise control over who experiences each feature. You can target users by geographic region, subscription tier, browser type, or any custom properties relevant to your application. These targeting rules operate independently per environment, supporting different rollout strategies for development, staging, and production.

Approval workflows introduce governance for sensitive changes. Flag modifications can require approval from designated reviewers before taking effect, ensuring critical features receive appropriate oversight. This capability becomes essential when feature flags control revenue-impacting functionality or security-sensitive behavior.

Cross-platform SDK support ensures consistent flag evaluation across diverse technology stacks. Whether your application uses mobile SDKs, web frameworks, or backend services, feature flags evaluate identically using the same configuration and targeting rules.

Analytics and monitoring provide visibility into flag usage, performance impact, and user experience. You can track flag impressions, identify stale flags consuming resources, and measure how feature changes affect key metrics.

Feature management organizes flags, environments, and applications in a hierarchical structure designed to match real-world software delivery practices.

Applications serve as organizational containers that group related feature flags, environments, and configurations. An application typically represents a single software product or service, though large systems may use multiple applications to maintain clean boundaries between different domains.

Environments represent deployment stages such as Development, QA, Staging, or Production. Each environment maintains its own configuration for feature flags while sharing the flag definitions themselves. This structure allows you to test different targeting rules in staging before applying them to production.

Feature flags exist within applications and automatically appear in all environments linked to that application. Flag metadata (name, type, description) remains consistent across environments, while configuration (targeting rules, rollout percentages, SDK keys) varies per environment.

The relationship creates a natural hierarchy: applications contain feature flags, environments provide runtime context, and SDK keys authenticate evaluation requests. When your application code requests a flag evaluation, it provides the SDK key (identifying the environment) and user properties (enabling targeting), then receives the appropriate flag value based on the current environment’s configuration.

Flag element scope refers to whether different parts of a feature flag definition are shared across all environments or configured separately for each environment. For example, a flag’s name stays the same in development and production, but its targeting rules can be different in each environment.

The table below shows which flag components are shared (✓) versus environment-specific (✗):

This scoping model ensures flag metadata remains consistent while allowing environment-specific behavior. Flag names, descriptions, and variations work identically across development, staging, and production, while targeting rules and rollout percentages adapt to each environment’s requirements.

This architecture supports both simple and complex deployment patterns. A basic web application might use a single application with Development and Production environments. A microservices architecture might require multiple applications, each with its own set of environments and flag configurations.

Feature management transforms how teams approach software delivery by providing new capabilities for risk management and user experience control.

Risk reduction through deployment decoupling represents the most fundamental benefit. Traditional deployments couple code changes with feature activation, creating an all-or-nothing release model. Feature flags allow you to deploy potentially risky features in an inactive state, then enable them gradually or instantly disable them if problems arise.

Instant kill switches provide emergency response capabilities for production issues. When a feature causes problems, you can disable it immediately without waiting for hotfix deployments. This capability proves invaluable for customer-facing issues that require immediate resolution.

License and entitlement management enables business model flexibility. Feature flags can expose premium functionality only to users with appropriate subscriptions or control access based on geographic regulations or compliance requirements.

Product experimentation and A/B testing becomes straightforward when features can be toggled for specific user segments. You can expose experimental features to small user groups, measure their impact, then decide whether to expand or remove them based on data rather than assumptions.

Release strategy flexibility supports advanced deployment patterns like canary releases and blue/green deployments. You can route traffic to new feature implementations gradually, monitor performance and user feedback, then complete or roll back the transition based on observed results.

Testing in production becomes safer when features remain disabled until explicitly activated. QA teams can validate functionality in real production environments without affecting regular users, catching issues that only surface under production conditions.

Feature management measures usage through client-side users (CSUs) to account for how client applications interact with feature flags.

A CSU represents a unique client instance that evaluates at least one feature flag during a 30-day billing period. Examples include mobile devices, browser sessions, or desktop applications. Multiple evaluations from the same instance within the billing period count as a single CSU.

This model reflects the reality of client-side applications where a single user might generate hundreds of flag evaluations through normal application usage. Rather than charging per evaluation, the CSU model provides predictable costs based on your actual user base.

The distinction between CSUs and monthly active users (MAUs) matters for billing accuracy. A user who accesses your application from both mobile and desktop devices generates two CSUs but represents one MAU. Understanding this difference helps with capacity planning and cost management.

Server-side SDKs typically don’t generate CSUs since they evaluate flags on behalf of users rather than representing individual client instances. This distinction supports architectures where backend services make flag decisions for multiple client applications.