🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português
🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português

Scope System

Scope System

The scope system controls where reusable FaceFlow sections are visible and shared.

For technical users, scope is one of the core architectural rules in FaceFlow. It decides whether a reusable section behaves like a global asset, a page-family asset, or a local page-only asset.

Three Scope Levels

  • Site: shared across the whole site
  • Layout: shared across Pages using the same Layout
  • Page: local to one Page

Technical Mental Model

Think of scope as a visibility and change-impact contract attached to a reusable section instance.

Conceptually:

{
  "component": "announcement-strip",
  "scope": "site"
}

The important field is not the exact storage shape. The important rule is that scope determines how broadly that instance should be reused and how widely a later edit will propagate.

Why Scope Matters

Scope prevents reuse from turning into chaos.

Without scope rules, teams either:

  • duplicate the same block everywhere
  • over-share one block that should have stayed local
  • lose track of which changes affect which Pages

Scope makes those boundaries explicit.

Mental Model

Site scope
  -> affects all relevant Pages across the site

Layout scope
  -> affects Pages that share one Layout

Page scope
  -> affects only one Page

This is not a content preference. It is a change-impact rule.

Example Instance Mapping

A simplified Page assembly might look like this:

Layout: docs-shell

Site scope:
  announcement-strip

Layout scope:
  docs-sidebar
  docs-subnav

Page scope:
  release-notes-cta
  migration-faq

That single diagram explains two important technical facts:

  • not every reusable section is equally shared
  • change review must account for scope before the edit is approved

Scope Examples

Site scope

Use when a section must behave as a site-wide asset.

Examples:

  • global announcement bar
  • shared navigation support strip
  • trust banner used across the whole site

Layout scope

Use when a section belongs to a page family.

Examples:

  • docs sidebar used only on documentation pages
  • shared sub-navigation for one service section
  • section-wide support rail for one layout family

Page scope

Use when the section is unique to one Page.

Examples:

  • a one-off campaign hero
  • a local CTA strip
  • page-specific FAQ or proof block

Change Radius Example

The same section type can be valid at different scopes depending on intent:

announcement-strip at Site scope
  -> change affects all relevant Pages

announcement-strip at Layout scope
  -> change affects one page family

announcement-strip at Page scope
  -> change affects only one Page

This is why scope should be chosen by intended blast radius, not by editor convenience.

Decision Rule

Ask one question:

If I change this section, which Pages should change with it?

If the answer is:

  • "all relevant Pages" -> Site
  • "Pages in this one family" -> Layout
  • "only this one Page" -> Page

Example Composition

Site scope:
  global-announcement

Layout scope:
  docs-sidebar

Page scope:
  pricing-faq

That model keeps reuse intentional and makes change impact predictable.

Architectural Guidance

Use scope to answer these technical questions:

  • where should this instance be discoverable?
  • how many Pages should inherit future edits?
  • who should own the change?
  • what level of review is justified before publishing?

In practice:

  • Site scope usually needs the strongest review because impact is broad
  • Layout scope needs page-family awareness
  • Page scope is the safest place for local experimentation

Technical Impact

Scope affects:

  • where a reusable section is available
  • how many Pages a change may affect
  • how teams reason about ownership
  • how shared structure is maintained over time

This is why scope decisions should be treated as architecture decisions, not editor convenience choices.

Review Pattern

When a team proposes widening scope, review it like an architectural change:

page -> layout
  question: is this section now shared by a durable page family?

layout -> site
  question: does this section now belong to the broader site, not one section?

If the answer is "not really", the scope is probably being widened too early.

Technical Review Checklist

  • does the chosen scope match the intended change radius?
  • is the section truly reusable at that level?
  • would a future editor understand why the section is shared?
  • is the section carrying content that should have stayed local?
  • is a supposedly local section being copied across many Pages?

Anti-Patterns

Avoid:

  • site scope for content that only one page family needs
  • page scope for content copied into many Pages
  • layout scope for content that belongs to the global site shell
  • widening scope just to save short-term effort

Example Rule in Practice

Main navigation utility bar -> Site scope
Developer docs sidebar -> Layout scope
Landing page final CTA -> Page scope

Scope should be reviewed together with object responsibility:

  • if the change affects the shell, review the Layout
  • if the change affects one reusable section contract, review the Component
  • if the change affects only one assembled experience, review the Page