> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scopes

A **scope** is a segmentation layer inside a Frontic project. Every project starts with a single scope called `public`; most projects never add another. Add a second scope when you need the same data to behave differently for a distinct audience — B2B alongside B2C, a wholesale storefront beside retail, a sub-brand that shares a catalog but shows different prices and copy.

Scopes are the coarsest layer of [Request Context](/api-builder/overview#request-context). Every request resolves to exactly one scope, and storage fields marked scoped can return a different value per scope — a product price that's `49.99` in `public` and `39.99` in `b2b`, or a description that's consumer-friendly in one scope and technical in another.

## When to add a scope

Don't reach for a scope the first time something varies — most variation is better served by [regions](/project-settings/regions) (market / currency), [locales](/project-settings/locales) (language), or a scoped field inside the default scope. A new scope is warranted when the split is about *who the customer is*, not *where or what language they speak*:

<CardGroup cols={2}>
  <Card title="B2B alongside B2C" icon="briefcase">
    Same products, different prices, different descriptions, possibly
    different availability. A separate scope keeps the two worlds clean
    without a parallel project.
  </Card>

  <Card title="Multi-brand portfolio" icon="palette">
    Sub-brands that share a product catalog but diverge on branding,
    naming, and merchandising. Each brand gets its own scope inside one
    project.
  </Card>

  <Card title="Wholesale vs retail" icon="warehouse">
    Wholesale customers see tier pricing and bulk MOQs; retail sees the
    consumer price. One scope per tier, same underlying data.
  </Card>

  <Card title="Staff-only variant" icon="user-shield">
    An internal-only scope for testing new copy or layouts ahead of a
    public rollout. Request context routing keeps it invisible to
    real traffic.
  </Card>
</CardGroup>

If the split is "two completely different experiences with different products and different flows", that's a case for two projects — not two scopes. Keep scopes inside one project; use [multiple projects](/essentials/core-concepts#project) when the codebase itself differs.

## How scopes relate to the rest

A scope is the top of the Request Context hierarchy:

1. A request arrives with a **scope** (resolved from a [domain](/project-settings/domains) or a `contextKey`).
2. Inside that scope, one of the scope's **[regions](/project-settings/regions)** is selected — the region carries a currency and a set of locales.
3. Inside that region, a **locale** is chosen — determines which translation is returned.

Every scope has its own regions. A region in `public` is not the same region as one in `b2b`, even if both are named "Germany" — they're distinct configuration objects with their own currencies and supported locales.

## Configuring scopes

Open **Settings → Scopes** from a project. The scopes list shows every scope with its region count.

<Screenshot name="project-settings/scopes-list" caption="Scopes list — one card per scope with regions nested inside" alt="Project Settings Scopes page showing the public scope with region count" />

Click a scope to open its detail view, where you add or edit the regions that live inside it.

<Screenshot name="project-settings/scope-detail" caption="Scope detail — regions, currencies, and supported locales nested inside the scope" alt="Scope detail view showing the scope's name, key, and a list of region cards each with currency and locale information" />

Scope-level settings themselves are thin — a scope's identity is mainly its `key` (used in API responses and field mappings) and the regions attached to it.

## The default scope

Exactly one scope on a project is flagged as the **default** — used when a request arrives without enough context to pick a scope explicitly (no domain match, no `contextKey` carrying a scope). On a fresh project that's the `public` scope.

## Scoped fields

A field on a [Data Storage](/data-integration/data-storages) or [Block](/api-builder/blocks) can be marked **Scoped**. A scoped field stores one value per scope rather than one shared value. When the API responds to a request in scope `b2b`, the `b2b` value for that field is returned; when it responds to `public`, the `public` value is returned. No per-scope forking in your frontend — the API surface stays the same, only the payload changes.

Reach for a scoped field when only *part* of a record differs per audience — a price, a description, a hero image. If every field of a record would differ, that's a sign the segmentation belongs elsewhere (a separate record, a separate block, or a separate scope altogether).

## Related

<CardGroup cols={2}>
  <Card title="Regions" icon="earth-americas" href="/project-settings/regions">
    Geographic markets that live inside a scope, each with its own
    currency and locales.
  </Card>

  <Card title="Multi-channel & region" icon="sitemap" href="/commerce-concepts/multi-channel-region">
    The full commerce-native picture — scopes, regions, locales, domains
    working together.
  </Card>

  <Card title="Request Context" icon="brain" href="/api-builder/overview#request-context">
    How a request resolves to one scope/region/locale combination.
  </Card>

  <Card title="Domains" icon="globe" href="/project-settings/domains">
    Where scope/region/locale is bound to an incoming URL.
  </Card>
</CardGroup>