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. 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 (market / currency), 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: 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 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 or a contextKey).
2. Inside that scope, one of the scope’s 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. Click a scope to open its detail view, where you add or edit the regions that live inside it. 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 or Block 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