Work · Module
Feature Flags
Separate deploy from release with targeting, progressive rollout and kill switches
Feature Flags releases changes safely by separating deploy from release: targeted and progressive rollouts, kill switches, remote configuration and cleanup of stale flags. It also powers assignment for Experimentation.
What it does
Feature Flags is an add-on eligible from W4. It lets teams merge code with a feature switched off, release it to internal users first, roll it out in steps and turn it off instantly if something goes wrong.
Flags and targeting
Flags can be boolean, multivariate or JSON, with separate states per environment (development, staging, production and custom). Targeting rules use context attributes, percentage rollout, allow and deny lists and reusable segments. Remote config delivers typed configuration values per environment and segment.
SDKs that do not depend on the network
Server and client SDKs evaluate locally from streamed rule sets, with OpenFeature-compatible providers (verify specification version). After initialisation, no network call is needed per evaluation. If an SDK cannot reach One3, it serves the last known rules or the coded default. Client-side keys can only read flags marked client-available. SDKs hash identifiers by default, and evaluation context must not include personal data unless the tenant marks it and the data classification allows.
Safe rollout
Progressive rollout moves in scheduled percentage steps with guardrail metrics, and a step never advances while a guardrail is breached. Every flag has a coded safe default, and the kill switch returns to it in one click, recording who, when and why. Production changes are R3 with a preview of affected segments, while development and staging changes are R1 unless the tenant tightens policy. History keeps versioned rule sets with diffs, scheduled activation and exact revert.
Flag hygiene
Stale flag detection lists flags fully rolled out or unused for a set period and offers to create a cleanup issue in Issues & Sprints. Flags link to issues, releases and experiments.
GA additions
GA plans include flag prerequisites with cycle detection, a self-hosted relay proxy for private networks and One3 Box deployments that keeps serving the last synced rules when disconnected, code references found through DevHub, evaluation analytics, approval policies per environment with change windows and freeze periods, reusable release pipelines, and flag triggers that let a monitoring tool turn a flag off through a signed webhook.
Agents may propose rollout steps and cleanups. Production changes by agents follow earned autonomy and are never allowed during a freeze period.
Features
What Feature Flags includes
Flags and environments
Boolean, multivariate and JSON flags with separate states per environment.
Targeting and segments
Attribute rules, percentage rollout, allow and deny lists and reusable segments.
SDKs with local evaluation
Streamed rule sets, offline fallback to last known rules and OpenFeature providers.
Progressive rollout
Scheduled steps gated by guardrail metrics with pause proposals on breach.
Kill switch and change control
One-click return to the safe default; production changes R3 with segment preview.
History and scheduled changes
Versioned rules, diffs, scheduled activation and exact revert.
Remote config
Typed configuration values per environment and segment.
Stale flag detection
Cleanup suggestions and issue creation for flags fully rolled out or unused.
Links
Flag to issue, release and experiment traceability.
Relay proxy
Self-hosted relay for private networks and sovereign deployments (GA).
Approval policies and release pipelines
Required approvers, change windows, freeze periods and reusable phased pipelines (GA).
Flag triggers
Signed webhooks that let monitoring tools turn a flag off, logged and rate-limited (GA).
Workflow
Release behind a flag
- 1
Merge code with the flag off and deploy
- 2
Enable for an internal segment
- 3
Roll out a small percentage in production with R3 approval
- 4
If guardrails are unhealthy, pause or kill to the safe default
- 5
Advance steps on schedule to 100 percent
- 6
After the stale period, create a cleanup issue in Issues & Sprints
AI
AI skills and Digital Employees
Stale flag detection
Finds flags ready for cleanup and drafts the issue.
Rollout step proposals
Proposes the next step from guardrail health.
Change impact explanation
Explains affected segments and evaluation volume before a change.
Evaluation context PII check
Warns flag admins when SDK payloads carry personal data.
Digital Employees that use this module
They act through the same governed Actions as people; risky steps wait for approval.
Frequently asked questions
What happens if our app cannot reach One3?
SDKs keep serving the last known rules or the coded default. With the planned relay proxy, SDKs in a private network keep working while the relay is disconnected.
Can an agent change production flags?
Agents can propose rollout steps. Production changes are R3, follow earned autonomy and are never allowed during a freeze period.
Do flags collect personal data?
SDKs hash identifiers by default, and personal data fields are excluded from evaluation context unless the tenant marks them and its data classification allows.
See Feature Flags in your workflow
Tell us about your team and the outcomes you want. We will walk you through the apps, the Digital Employees and the plan for your industry.