SOASAP
Sign In Sign Up Free

Create Your First Flag

Create a boolean flag in the dashboard and verify it in your application.

Introduction

A feature flag is a named configuration value that applications read at runtime. Feature flags allow teams to change behavior without redeploying code.

This guide demonstrates the simplest possible flag: a Boolean flag. If you have not set up a project or SDK yet, start with Quick Start.

What you will create

Key new-checkout
Type Boolean
Initial value false
Purpose Enable or disable a new checkout experience without redeploying the application.

Steps

  1. Step 1 — Open the flags page

    Sign in to the SOASAP dashboard and open your project. Navigate to the flags section for the environment you are testing — use Development for local work.

  2. Step 2 — Create a boolean flag

    Create a new flag with key new-checkout, type Boolean, and initial value false in Development.

    Project vs environment — one of the most important concepts in SOASAP:

    • Flag key and type belong to the project — defined once, shared across environments
    • Flag value and enabled state belong to each environment
    • The same key can be true in Development and false in Production
  3. Step 3 — Save the flag

    Save your changes in the dashboard. SOASAP stores the authoritative configuration and streams updates to connected SDKs over SSE — typically within sub-second time on healthy networks.

  4. Step 4 — Verify in your application

    With your SDK initialized (see Quick Start), read the flag in your application:

    client.getBool("new-checkout", false)

    Log the result in non-production to confirm the key, environment, and API key match. You should see false while the flag is disabled in Development.

  5. Step 5 — Toggle the flag

    Return to the dashboard and enable new-checkout in Development.

    Your application should reflect the change within seconds without a redeploy or restart — subsequent reads return true.

Expected result

Flag disabled:

client.getBool("new-checkout", false) → false

Flag enabled:

client.getBool("new-checkout", false) → true

When the flag is enabled in the dashboard, the SDK receives the update through SSE and subsequent evaluations return the new value — without requiring a redeploy.

Success checklist

  • ✓ Flag created
  • ✓ SDK successfully reads the flag
  • ✓ Dashboard changes update the value
  • ✓ No redeploy required
  • ✓ Development environment behaves as expected

What just happened?

When you toggled the flag, SOASAP Cloud pushed the update to your SDK over Server-Sent Events (SSE).

The SDK updated its local snapshot. Your next getBool("new-checkout", false) call read the new value from memory.

No redeploy required. The application binary did not change — only the synchronized configuration did.

Key concepts learned

  • ✓ Flags are defined at project scope
  • ✓ Values are configured per environment
  • ✓ SDKs evaluate flags locally
  • ✓ Changes propagate through SSE
  • ✓ No redeploy is required

Production safety

Local evaluation shifts responsibility for safe behavior to your application code. Always pass an explicit default when reading a flag:

client.getBool("new-checkout", false)

Why defaults matter: if a flag key is missing from the snapshot — before the first sync, after deletion, or during an outage — the SDK returns the default you provide in code. Defaulting new features to false prevents a missing flag from implicitly enabling risky behavior.

Details: Default Values and Production Safety.

Next steps

  • Feature Flags — learn about Boolean, String, Number, and JSON flags.
  • SDK Installation — platform-specific integration guides.
  • Architecture — understand local evaluation, SSE synchronization, persistent cache, and offline operation.

Background: Core Concepts and Quick Start.