How to enable B2B SaaS features for specific customers

In B2B SaaS, not every customer gets the same experience.

Enterprise accounts might get advanced analytics, strategic partners may receive early access to beta tools, and internal teams could have exclusive admin capabilities. But managing who gets what can quickly become a headache, especially if you’re still hardcoding access checks or relying on ad-hoc methods.

Controlling feature availability per customer is a core part of scaling a SaaS product. Done right, it can unlock faster sales, smoother rollouts, and higher customer satisfaction. Done poorly, it can lead to messy code, long deployment cycles, and frustrated teams.

In this article, we’ll explore practical ways to manage feature access for specific customers, why feature flags are such a strong fit for both per-customer control and gradual rollouts, and how to set them up without building a complex entitlement system from scratch. We’ll wrap up with a step-by-step walkthrough using WorkOS Feature Flags, a tool built specifically for B2B SaaS teams that want organization-level feature control with minimal engineering overhead.

Why use feature flags for B2B SaaS?

Feature flags aren’t just for A/B testing button colors. They are a powerful tool for controlling access in multi-tenant, organization-based apps.

In B2B SaaS, they’re typically used in two main ways:

• As customer entitlement flags: Flags tied directly to an organization’s plan, contract, or custom agreement. These are long-lived and function as part of your access control layer. Examples:
  • Enable a new feature for one customer: Assign the flag only to their org.
  • Unlock Enterprise plan perks: Toggle on multiple features instantly after an upgrade.
  • Enable sales demos for prospects: Turn on high-value features for 24 hours.
  • Support overrides: Temporarily enable a feature for debugging.
• As rollout or experiment flags: Flags used for gradually releasing features to reduce risk, gather feedback, or run limited pilots before a full launch. Examples:
  • Internal beta testing: Enable flag for your internal org only.
  • Soft launch: Roll out to a small set of early-adopter customers before general availability.
  • Gradual migration: Keep both old and new versions of a feature live, switching customers over in phases.

These scenarios make feature flags more than a development tool. They become a sales, support, and product enablement asset.

Common ways to manage feature access

• Hardcoded checks in the codebase: Directly add logic in your application code to decide which customers see which features. It’s simple to implement but requires redeploys for every change and quickly becomes unmanageable as your customer base grows.
• Configuration files or environment variables: Store feature access rules in config files or env vars that the app reads at runtime. This approach is slightly more flexible since it’s easier to update than code, but still requires engineering involvement and runs a high risk of version drift between environments.
• Custom entitlements system: Maintain a database table mapping customers to their enabled features. It’s very flexible, but it can take significant engineering time to build and maintain.
• Third-party feature management tools: Use a purpose-built service to toggle features without redeploying. It enables instant changes and can support both rollouts for new features and per-customer access, but adds a dependency on an external service.

While all of these approaches can work for implementing feature flags, they vary in flexibility, maintainability, and speed. For B2B SaaS, where feature access often needs to be managed at the organization level, an approach that’s purpose-built for org-based entitlements can save significant engineering time. That’s exactly what WorkOS Feature Flags provide, so let’s walk through how they work and how to set them up.

How WorkOS Feature Flags work

When a user logs in via AuthKit, their JWT (access token) includes a feature_flags claim:

	
{
"iss": "https://api.workos.com",
"sub": "user_01HBEQKA6K4QJAS93VPE39W1JT",
"sid": "session_01HQSXZGF8FHF7A9ZZFCW4387R",
"jti": "01HQSXZXPPFPKMDD32RKTFY6PV",
"org_id": "org_01HRDMC6CM357W30QMHMQ96Q0S",
"role": "member",
"permissions": ["posts:read", "posts:write"],
"exp": 1709193857,
"iat": 1709193557,
"feature_flags": ["feature-1", "feature-2"]
}
	

You can check this claim directly in your frontend or backend; no additional API calls needed.

This makes gating features as simple as:

	
if (featureFlags.includes("advanced_analytics")) {
  renderAnalyticsDashboard();
}
	

Let’s see how exactly you can do this.

Step 1: Create a feature flag

Head to the WorkOS dashboard > Feature Flags.

Create a new flag by specifying a name and a slug. You can optionally specify a description for the flag and assign tags for filtering.

Step 2: Assign the flag to an organization

Each feature flag can be enabled for none, some, or all of your organizations.

Feature flags are available across all environments, but organization-specific rules are configured separately in each one. This makes it easy to isolate and test changes in staging or development before rolling them out to production. For example, you can enable a new dashboard feature for Acme Corp in staging without affecting their experience in production.

To edit organizations that should have the feature flag enabled, click Edit on the organizations rule for the environment you want to edit. Next, select your desired organization rule setting between None, Some, and All. Selecting Some will allow you select specific organizations.

To edit a feature flag’s rules in other environments, click the Edit in X button which will update your active dashboard environment to the selected environment, allowing you to update rules in the chosen environment.

Step 3: Enable the feature flag

Once you’re ready to enable the feature for the configured organizations, toggle the flag on to start including it in a user’s access token when they authenticate for a configured organization.

Step 4: Use the feature flag in your app

Feature flags will show up in the access token the next time the user logs in or the session is refreshed. You can manually refresh the session after granting the organization access in the dashboard.

Here’s an example in Express:

	
app.get('/api/feature-flags', async (req, res) => {
  // load the original session
  const session = workos.userManagement.loadSealedSession({
    cookiePassword: process.env.WORKOS_COOKIE_PASSWORD,
    sessionData: req.cookies['wos-session'],
  });

  const { sealedSession, featureFlags } = await session.refresh();

  // set the updated refresh session data in a cookie
  res.cookie('wos-session', sealedSession, {
    httpOnly: true,
    sameSite: 'lax',
    secure: true,
  });

  // return the feature flags to the client
  res.json({
    featureFlags,
  });
});
	

Best practices

• Name flags predictably: Use a consistent prefix or format (feature_advanced_analytics, flag_priority_support) so it’s obvious what they control.
• Document the purpose and scope: Every flag should have a clear description in the dashboard: What does it enable? Who is it for? Is it temporary or permanent? When should it be removed?
• Know the two common patterns: Treat each type differently in terms of lifecycle, naming, and clean-up:
  • Customer entitlement flags: Long-lived, tied to contracts, plan tiers, or custom features for specific organizations.
  • Rollout or experiment flags: Short-lived, used for gradually introducing a feature or testing with a subset of customers before enabling it more broadly.
• Audit regularly: Review all active flags every quarter. For entitlement flags, verify they match current customer agreements. For rollout flags, remove them once the rollout or experiment is complete.
• Tie flags to CRM or billing systems: Automate flag toggles when a customer upgrades, downgrades, or enters a beta program.
• Avoid flag overload: Consolidate where possible. If multiple features are always enabled together, group them under a single flag to reduce complexity.

Final thoughts

Feature flags are a powerful way to manage which customers get which features, whether you’re granting long-term entitlements based on contracts and plan tiers, or gradually rolling out something new.

By implementing them at the organization level, you make it easy to match your product’s behavior to your customer agreements, run targeted betas, and respond quickly to sales or support needs, without engineering having to push new code.

‍WorkOS Feature Flags take this a step further by giving you:

• Instant changes without deploys.
• Org-based access control built in.
• A single, safe interface for engineering and non-engineering teams alike.

Feature Flags are available for all AuthKit users at no additional cost. There’s no additional setup, no new API to wire up, and no infrastructure to manage.

‍Sign up for WorkOS today.