Skip to main content

FAQ

General​

Can I use feature flags from another application that I don't own?

Yes! Flag Controller supports cross-application flag consumption. When configuring your Provider, you use the flagSetId to scope flag evaluation to a specific application and environment. To evaluate flags from another team's application, set the flagSetId to that application's identifier.

Using flags from a single external application:

// Configure your provider with the other team's flag set ID
// flagSetId format: application-name-environment
// flagSetId: 'another-teams-application-production'

Using flags from multiple applications: If you need to consume flags from multiple applications in the same codebase, you can configure multiple providers using OpenFeature domains:

import { OpenFeature } from '@openfeature/server-sdk';

// Set up providers for different applications using domains
OpenFeature.setProvider("team-a", /* provider configured with flagSetId: 'team-a-application-production' */);
OpenFeature.setProvider("team-b", /* provider configured with flagSetId: 'team-b-application-production' */);

// Get clients for each domain
const teamAClient = OpenFeature.getClient("team-a");
const teamBClient = OpenFeature.getClient("team-b");

// Evaluate flags from different applications
const featureFromTeamA = teamAClient.getBooleanValue("feature-a", false);
const featureFromTeamB = teamBClient.getBooleanValue("feature-b", false);

See the Providers page for details on configuring your provider with the correct Flag Set ID. Learn more about multi-provider setup in the OpenFeature domains documentation.

Which browsers does Flag Controller support?

The Flag Controller UI and documentation are tested against and supported only in Google Chrome. We do not officially support other browsers at this time.

Targeting​

Does OpenFeature support contexts or any form of segmentation targeting?

OpenFeature + Flag Controller does support contexts and segmentation and we do support targeting. You can provide the input data using the evaluation context. OpenFeature has a great breakdown of how this works.

Framework Integration​

I'm looking to use feature flags in a Next.js app. Should I use the Node SDK on the server and the React SDK on the client?

Yes. The React SDK is designed for client-side usage and relies on React context, which isn't available on the server side. For Next.js applications that use both server and client side components, you have two main approaches:

Option 1: Use both SDKs

  • Use the Node SDK for server-side components
  • Use the React SDK for client-side components

Be mindful of the context used on the server versus the client if you decide to use both SDKs.

Option 2: Server-side evaluation with props

  • Evaluate all feature flags on the server side using the Node SDK
  • Pass the evaluated flag values down to client components as props
  • This approach can simplify your setup if you don't want to manage both SDKs

Both approaches are valid, and the choice depends on your specific use case and architecture preferences.

You can find the OpenFeature SDKs here:

You can find information on configuring your Provider here:

I'm evaluating a feature flag server side in Next.js, but even after the value changes my page is not reflecting the changes.

You might be statically rendering your page which causes the evaluated value to have existed at build time instead of evaluating at run time.

To ensure your feature flag's evaluated value is accurate on page refresh when using static pages in Next.js, you should consider using a dynamic route instead or leaning on the client-side OpenFeature evaluation hooks. Because static pages are generated at build and will not re-evaluate flags per user or per request, you'll want to opt for a dynamic route when evaluating flags server side.

Why static pages don't work well with feature flags:

  • Static pages are pre-rendered during the build process, meaning flag values are "baked in" at build time
  • The same static HTML is served to all users, so personalized targeting won't work
  • Flag changes won't be reflected until you rebuild and redeploy your application
  • User-specific context (like user ID, location, or custom attributes) cannot influence flag evaluation

Recommended approaches:

  • Use the App Router's dynamic rendering to evaluate flags per request
  • Implement client-side evaluation with React hooks for real-time flag updates
  • Consider using Incremental Static Regeneration (ISR) if you need some static benefits but want periodic updates
  • For pages that must be static, evaluate flags client-side after hydration

If you'd like to learn more about how static and dynamic rendering differ and how it impacts your ability to evaluate flags properly, reference the Next.js static and dynamic rendering guide.

Feature Flag Types​

What kinds of feature flag values does Flag Controller support?

Flag Controller supports boolean, number, text, and object type feature flags.

More on feature flag types.

Environments​

Does Flag Controller support multiple environments?

Flag Controller only supports two environments: production and development. You should use development for all non-prod environments.

This two-environment design is intentional for a few reasons:

  • The underlying infrastructure is split into just two real environments: nonprod and prod. An infrastructure problem in nonprod can impact all nonprod sub-environments.
  • Many organizations have semi-official nonprod subenvironments (like dev, QA, UAT, SIT, PT, Staging, and even SIT1, SIT2, QA1, QA2, etc.), which creates complexity and makes it difficult for teams to keep all environments in sync and stable.
  • By not explicitly offering multiple subenvironments, Flag Controller encourages teams to consider what environments they truly need and to simplify where possible.

This approach helps clarify the dividing lines for stability and connectivity, and reduces the overhead of managing many subenvironments.

Learn more here.

Governance​

What governance controls exist for feature flag rule creation and editing?

Flag Controller provides role-based access controls for managing feature flag rules. Users with appropriate permissions can create and edit targeting rules, while read-only users can view configurations but not make changes. All rule modifications are tracked in audit logs for compliance and oversight.

For production environments, additional approval workflows may be required depending on your organization's governance policies. The Flag Controller UI does not currently have mechanisms in place to aid the governance of creation and editing. However, we are looking to provide such mechanisms in the future.

Learn more about creating and managing rules here.

Are there governance controls for enabling/disabling feature flags in production?

Currently, Flag Controller relies on team membership for governance of feature flag operations. Only members of the team that owns a feature flag have the ability to modify it. We are actively developing more granular governance controls to provide teams with greater control over the lifecycle of their feature flags.

Production flag state changes are subject to audit logging and currently do not require an approval process within the UI.

Learn more about feature flag management here.

Rollouts and Bucketing​

How reliable are weighted rollouts and how does bucketing work across sessions?

Flag Controller uses flagd's fractional operation for weighted rollouts, which provides consistent and reliable bucketing. The bucketing algorithm ensures that users are consistently assigned to the same bucket across sessions based on their context attributes (typically user ID).

The fractional operation uses a deterministic hash function that takes the flag key and context attributes to assign users to buckets. This means a user will always receive the same flag value unless the weights or their context change.

Learn more about the bucketing implementation in the flagd fractional operation documentation and specification.

Privacy and Security​

Does Flag Controller use cookies for feature flag evaluation?

No, Flag Controller does not use cookies for feature flag evaluation. All targeting and bucketing decisions are made based on the evaluation context provided by your application, without relying on browser cookies or client-side storage.

Can I use PII (Personally Identifiable Information) in feature flag evaluation context?

Using PII in feature flag evaluation context is strongly discouraged for privacy and security reasons. While technically possible, you should avoid including sensitive personal information like email addresses, phone numbers, or other identifying data in your evaluation context.

Instead, use non-sensitive identifiers or hashed values. For more guidance on proper context usage and PII considerations, see our documentation on feature flag rules and segment management.

Configuration Management​

Can I change feature flag, segment, or rule keys after creation?

No, feature flag keys, segment keys, and rule keys are immutable and cannot be changed once created. This ensures consistency and prevents breaking changes in your application code that references these keys.

If you need to change a key, you must create a new flag/segment/rule with the desired key and update your application code to reference the new key, then remove the old one once the migration is complete.

Learn more about feature flag management and segment management.