Notifications
Clear all
Topic starter
07/06/2026 8:30 pm
TL;DR: Enterprise software teams are using organization-aware feature flags to separate deployment from customer visibility, letting code ship on engineering timelines while rollout follows account-level change tolerance, support readiness, and enablement needs, according to WorkOS. For IAM and identity leaders, the lesson is that entitlement, audience targeting, and communication now matter as much as release velocity.
NHIMG editorial — based on content published by WorkOS: Feature Flags as a Change Management Strategy for B2B Apps
Questions worth separating out
Q: How should security and platform teams govern feature flags in B2B apps?
A: They should govern feature flags at the organisation level, not the user level, so everyone in a customer tenant sees the same experience unless an exception is deliberate and documented.
Q: Why do tenant-level feature flags matter for enterprise customers?
A: Tenant-level flags prevent split-brain experiences inside the same account.
Q: What breaks when feature flags are used only as experimentation tools?
A: They stop reflecting the way enterprise software is actually adopted.
Practitioner guidance
- Map feature rollout to organisation context Use account-level targeting so all users in a tenant see the same feature state unless there is a documented exception.
- Treat feature flags as governed exposure controls Define who can enable, disable, or stage a flag, and tie those decisions to release readiness, customer success, and contractual requirements.
- Bind flag state to authenticated session claims If the application reads feature flags from a JWT or similar session artifact, ensure refresh behaviour matches rollout speed and rollback needs.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Environment-by-environment flag setup and how None, Some, and All targeting behaves in practice.
- JWT claim injection details for feature flag delivery through the authentication flow.
- Rollout patterns for PLG, beta, enterprise, and strategic accounts using CSM-managed timing.
- Operational examples of how support and account managers can request flag changes for specific organisations.
👉 Read WorkOS's article on feature flags as change management for B2B apps →
Feature flags for B2B apps: what changes for IAM teams?
Explore further
07/06/2026 10:26 pm
Organization-aware feature flags are really governance controls, not just delivery controls. The article shows that the real problem is not shipping code but controlling exposure across account boundaries. Once availability becomes a policy decision, identity context becomes part of release governance, which is why this belongs in the same conversation as entitlement design and lifecycle control. Practitioners should stop treating flags as a frontend convenience and start treating them as a governed access boundary.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, a reminder that one exposed identity often becomes a repeatable access problem, not a one-off event.
A question worth separating out:
Q: How do teams reduce rollout risk without slowing deployment?
A: They should separate deployment from availability, then pair fast shipping with clear communication, documentation, and account-manager control. That lets code reach production while customer exposure follows business readiness. The result is faster iteration without forcing every customer onto the same change timetable.
👉 Read our full editorial: Organization-aware feature flags reshape enterprise change control
