Boolean Flags

Introduction

Boolean flags store one of two values: true or false. They are the simplest and most commonly used flag type in SOASAP.

Applications use Boolean flags to enable or disable functionality without redeploying code. The SDK evaluates the flag locally from an in-memory snapshot — no network request occurs on the read path.

Common use cases:

• Feature releases — route traffic to a new implementation when ready
• Kill switches — disable a risky path immediately from the dashboard
• Maintenance mode — return degraded responses while work is in progress
• Gradual rollouts — enable a feature in Development and Staging before Production
• Legacy vs new implementations — switch between code paths at runtime

When to use Boolean flags

Use a Boolean flag when behavior reduces to a binary decision: on or off, enabled or disabled.

Feature release — gate a new user-facing flow behind a flag. Ship code with the flag off; enable it per environment when validated.

Kill switch — invert the usual pattern: the flag name describes the failure state (disable-payments). When true, block the operation. Default to false so a missing flag never disables payments.

Maintenance mode — return HTTP 503 or a static maintenance page when enabled. Default to false so outages in flag sync do not take the site offline.

Operational controls — start or stop background workers, schedulers, or batch jobs. Default to true when the job is required for normal operation and disabling it is the exceptional case.

If you need more than two states — modes, tiers, or multi-value configuration — use String or JSON flags instead.

Create a Boolean flag

Create flags in the SOASAP dashboard. If you have not set up a project yet, start with Create Your First Flag.

1. Open your project

   Sign in to the dashboard, select your project, and open the environment where you want to configure the initial value — typically Development for local work.

2. Create the flag

   Add a new flag with the following properties:

   Key	new-checkout
   Type	Boolean
   Initial value	false

3. Save and verify

   Save the flag. Connected SDKs receive the update over SSE. Read the flag in your application to confirm the value matches the dashboard for that environment.

Example configuration for new-checkout:

Each environment uses its own API key. The SDK bound to the Production key reads Production values only.

Evaluate a Boolean flag

SDKs evaluate Boolean flags locally from an in-memory snapshot. The getter returns true or false synchronously — no HTTP request, no disk I/O, and no dependency on SOASAP Cloud availability at read time.

Method names vary by SDK; the semantics are identical.

.NET

var enabled = client.GetBool(
    "new-checkout",
    defaultValue: false);

Node.js

const enabled = flags.getBool(
    "new-checkout",
    false,
);

Python

enabled = flags.get_bool(
    "new-checkout",
    False,
)

Kotlin

val enabled = client.getBool(
    "new-checkout",
    defaultValue = false,
)

React / React Native

const newCheckout = useSoasapBool("new-checkout", false);

Flag evaluation never performs network requests. Values are read from the local SDK snapshot. Background synchronization (SSE) updates the snapshot; subsequent reads return the new value without a redeploy. See Local Evaluation.

Explicit defaults

Always provide a default value on every Boolean read:

client.GetBool("new-checkout", defaultValue: false);

The default is returned when:

• The flag key does not exist in the synchronized snapshot
• The flag was deleted or disabled in the dashboard for this environment
• Synchronization has not completed and no cached snapshot is available
• The restored disk or browser cache is empty or invalid
• The stored value is not a Boolean (type mismatch)

Explicit defaults are your production safety net. They define application behavior when configuration is missing, stale, or not yet synchronized — without try/catch on the hot path. Getters never throw.

Details: Default Values.

Common usage patterns

Feature release

Route users to a new implementation when the flag is enabled. Default to the legacy path when the flag is off or missing.

if (client.GetBool("new-checkout", defaultValue: false))
{
    return NewCheckout();
}

return LegacyCheckout();

Kill switch

Block a dangerous or degraded code path immediately from the dashboard. Name the flag after the failure action; default to false so normal operation continues when the flag is absent.

if (client.GetBool("disable-payments", defaultValue: false))
{
    return ServiceUnavailable();
}

Maintenance mode

Return a degraded response site-wide or per-route while maintenance is in progress. Default to false — maintenance should be an explicit operator action, not an accidental default.

if (client.GetBool("maintenance-mode", defaultValue: false))
{
    return Results.StatusCode(503);
}

Background jobs

Control whether a worker or scheduler runs. Default to true when the job is part of normal operation and stopping it is the exceptional case.

if (client.GetBool("enable-background-jobs", defaultValue: true))
{
    jobRunner.Start();
}

Runtime behavior

1. An operator changes a flag value in the dashboard for a specific environment
2. SOASAP Cloud pushes the update to connected SDKs over Server-Sent Events (SSE)
3. The SDK validates the payload and atomically replaces its in-memory snapshot
4. Subsequent getBool / GetBool calls return the new value

No redeploy is required. No network requests occur during evaluation — only during background synchronization. Propagation is typically sub-second on healthy networks; reads during disconnect continue using the last known snapshot.

See Real-Time Synchronization and Offline Operation.

Production recommendations

Common mistakes

Generic flag names

Avoid:

client.GetBool("enabled", defaultValue: false);
client.GetBool("feature", defaultValue: false);

Prefer:

client.GetBool("new-checkout", defaultValue: false);
client.GetBool("maintenance-mode", defaultValue: false);

Generic names become ambiguous as flag count grows. Descriptive keys make code reviews, incident response, and cross-team coordination easier.

Leaving temporary rollout flags indefinitely

Branching code guarded by new-checkout should be temporary. After full rollout, remove the flag from the dashboard and delete the legacy branch from code. Stale flags increase cognitive load and create false confidence about which path Production actually executes.

Using Boolean flags for multi-state configuration

Booleans encode two states. Using multiple Boolean flags to represent mutually exclusive modes (for example, use-theme-a and use-theme-b) leads to invalid combinations and race conditions during dashboard edits.

Use a String flag (ui-theme → "light" | "dark") or a JSON flag for structured multi-field configuration.

Related documentation

• String Flags — text values for modes, themes, and labels
• Number Flags — limits, rates, and thresholds
• JSON Flags — structured remote configuration
• Feature Flag Best Practices — inventory hygiene and rollout patterns
• Naming Conventions — key format and consistency
• Architecture — local evaluation, SSE, cache, and offline operation
• SDK Documentation — install and configure your platform SDK