Shared Concepts
Cross-platform rules and models that hold across every SGEN surface — the vocabulary the rest of the documentation assumes.
In short. Shared Concepts is the vocabulary layer that every other SGEN Reference page assumes. The key ideas: site context (working inside one site's own admin, which affects just that site) vs account context (working in your SG-Dashboard account portal, which affects your whole portfolio); environment separation (staging and live are first-class, promotion is governed); ownership boundaries (SG-Dashboard = account-tier, SG-Admin = site-tier, SG-Builder = page-tier); structured administration (everything is a typed record — pages, products, forms — with creation flows and publishing states). Read this once during onboarding; revisit when terminology from another Reference page lands ambiguously. That's the gist — everything below is the same idea in depth.
Overview
Shared Concepts are the cross-platform rules, models, and operating ideas that remain consistent across SG-Dashboard, SG-Builder, Workflows, Automation, Integrations, and Migration and Import. This area provides a stable conceptual layer for the wider platform rather than a description of any one isolated surface.
This page is the Reference definition of the Shared Concepts surface. It establishes the common terminology and platform logic that other Reference areas depend on, so support, implementation, onboarding, and internal documentation share a model for interpreting how the system behaves across multiple surfaces.
A reference list view in SG-Admin for the Shared Concepts module, shown at the Hero surface. It lists the module name (Shared Concepts), its page slug (shared-concepts-index), and the surface it belongs to (Shared Concepts / Hero).
Screenshot pending. This inline reference mock stands in for a captured screenshot of the Hero surface and will be replaced once the screenshot is available.
What is this for?
Read this page when you need the cross-platform vocabulary the rest of the Reference library assumes:
- Site context and account context
- Environment separation
- Ownership boundaries
- Surface responsibility
- System relationships that hold the platform together as one operating model
This page is a Reference definition. It does not walk you through any procedure. Step-by-step procedures live in Guides. Per-surface capability detail lives in the SG-Dashboard, SG-Admin, and SG-Builder Reference sections.
Good use cases
- You are new to SGEN and need the cross-platform vocabulary before you start opening per-surface Reference pages.
- You are explaining the platform to a stakeholder, an in-house operator, or an agency client and need the shared model.
- You are scoping a multi-team operations workflow and need the boundary model laid out plainly.
- You hit terminology in another Reference page and want the canonical definition.
- You are writing your own internal docs against SGEN and need the platform vocabulary to anchor your team's documentation.
What NOT to use this for
- Per-surface deep detail — open the corresponding surface's Reference page (SG-Dashboard, SG-Builder).
- Step-by-step procedures — open the relevant Guide.
- Per-release behavior change — open What's New or Changelog.
- Marketing claims about SGEN's positioning — the SGEN marketing site is the marketing surface.
- Per-customer infrastructure detail — escalate to support.
How this connects to other features
- Platform Overview — the system map that places Shared Concepts inside the wider Reference library.
- SG-Dashboard Overview — the account-tier surface that applies Shared Concepts to multi-site control.
- SG-Admin Overview — the site-tier surface that applies Shared Concepts to record administration.
- SG-Builder Overview — the page-tier surface that applies Shared Concepts to visual composition.
Definition
Shared Concepts are the cross-platform rules, models, and operating ideas that remain consistent across SG-Dashboard, SG-Builder, Workflows, Automation, Integrations, and migration-sensitive operations. The area provides a stable conceptual layer for the wider platform rather than a description of one isolated surface.
The defining property is recurrence. A concept lives in Shared Concepts when it appears across more than one surface and would otherwise be redefined inconsistently in each per-surface Reference page. Centralizing the definition here lets per-surface pages assume the model without restating it — keeping the documentation legible at scale.
Purpose
This page establishes the common terminology and platform logic that other Reference areas depend on. It gives the following audiences a shared model for interpreting how the system behaves across multiple surfaces:
- Support teams triaging cross-surface tickets
- Implementation teams configuring new accounts
- Onboarding readers starting from Platform Overview
- Internal documentation authors writing SOPs against SGEN
A reference list view in SG-Admin for the Shared Concepts module, shown at the Surface surface. It lists the module name (Shared Concepts), its page slug (shared-concepts-index), and the surface it belongs to (Shared Concepts / Surface).
Screenshot pending. This inline reference mock stands in for a captured screenshot of the Surface view and will be replaced once the screenshot is available.
Scope
This page covers shared platform concepts at the Reference level. It does not act as a procedural guide, a screen walkthrough, or a release note. It should be read as a conceptual reference for the rules and models that appear repeatedly across the SGEN stack.
The page covers:
- Rules and models that apply beyond a single product surface.
- A common language for interpreting platform behavior.
- Consistent reading across Dashboard, Admin, Builder, Workflows, Automation, Integrations, and Migration-related references.
- The conceptual backbone every other Reference page can assume without restating.
The page does not cover:
- Per-surface capability detail — corresponding surface Reference pages.
- Per-area procedures — Guides.
- Per-release shipped change — What's New or Changelog.
- Internal engineering implementation — internal-only documentation.
Responsibilities
The Shared Concepts area is responsible for keeping cross-platform understanding consistent.
Concept definition
Defines the shared models and operating ideas that appear across the wider SGEN platform — site context, environment separation, ownership boundaries, structured administration, platform-level flow continuity. Each concept has a single canonical definition here and is referenced from elsewhere rather than redefined.
Terminology alignment
Provides a stable vocabulary for support, implementation, onboarding, and product documentation. The vocabulary on this page is the vocabulary the rest of the docs use. Per-team or per-customer renaming should adapt to this vocabulary, not the other way around.
Cross-surface consistency
Reduces interpretation drift when operators move between Dashboard, Admin, Builder, Workflows, and system-level Reference areas. A concept defined once here behaves the same way every time it appears downstream.
A reference list view in SG-Admin for the Shared Concepts module, shown at the Vocabulary surface. It lists the module name (Shared Concepts), its page slug (shared-concepts-index), and the surface it belongs to (Shared Concepts / Vocabulary).
Screenshot pending. This inline reference mock stands in for a captured screenshot of the Vocabulary view and will be replaced once the screenshot is available.
Key concepts
Shared Concepts covers platform-wide ideas such as ownership boundaries, cross-surface responsibility, system models, operational separation, and recurring rules that should not be redefined differently in every section.
| Concept Family | What it covers |
|---|---|
| Surface responsibility | Defines which platform surface owns account-level control, site administration, visual composition, or background behavior. SG-Dashboard owns account-tier; SG-Admin owns site-tier; SG-Builder owns page-tier. |
| Operating models | Defines shared models such as site context, environment separation, structured administration, and platform-level flow continuity. |
| System relationships | Clarifies how major surfaces and supporting layers fit together as one governed platform rather than isolated tools. |
| Reference continuity | Provides the conceptual backbone that other Reference pages can assume without restating the full platform model every time. |
Site context vs account context
Site context is the operating context inside one site's own admin — work in this context affects the active site's content, settings, modules, or layout. Account context is the operating context inside your SG-Dashboard account portal — work in this context affects the account portfolio, billing, multi-site reporting, or invitations.
The boundary between site context and account context is structural. Operators switch contexts intentionally — opening a site card from SG-Dashboard moves into that site's admin (site context); navigating back to the dashboard returns to account context. The browser address bar tells you which context you are in: your own site's domain for site context, the SG-Dashboard portal for account context.
Environment separation
Staging and live are first-class environments, not an afterthought. Promotion from staging to live is a governed operation; the platform owns the surface that moves change from one environment to the other. Environment separation applies to content, settings, themes, and layout — anything publishable has staging and live counterparts.
Ownership boundaries
Each operating surface owns a clear scope. SG-Dashboard owns account-tier operations; SG-Admin owns site-tier records and configuration; SG-Builder owns page-tier layout and presentation. Features land on the tier whose shape matches the feature's shape; cross-tier features split into the parts that belong on each tier.
Structured administration
Site state is administered through structured records — Pages, Posts, Products, Forms, Custom Objects, Locations, Events. Each record type has a defined schema, a creation flow, an inventory view, and a publishing model. Structured administration is the shape SG-Admin enforces across every module.
A reference list view in SG-Admin for the Shared Concepts module, shown at the Concepts surface. It lists the module name (Shared Concepts), its page slug (shared-concepts-index), and the surface it belongs to (Shared Concepts / Concepts).
Screenshot pending. This inline reference mock stands in for a captured screenshot of the Concepts view and will be replaced once the screenshot is available.
A side-by-side view of the two operating contexts: the SG-Dashboard account portal (billing, site provisioning, multi-site reports, support tickets, account invitations) and one site's own admin (records, per-site settings and theme, custom codes and fonts, per-site users, and visual editing in SG-Builder). Account context manages your whole portfolio; site context manages one site — and the address bar tells you which one you are in.
Screenshot pending. A captured screenshot of the two operating contexts side by side will replace this description once available.
Operational role
Shared Concepts is the common interpretive layer of the SGEN Reference library. Readers use it when they need to understand:
- How the platform separates its surfaces
- What recurring system rules hold across multiple parts of the product
- How the platform vocabulary maps to observable behavior
In daily operator use, Shared Concepts is read once during onboarding and revisited when terminology lands ambiguously somewhere downstream. It is not a working surface — there is nothing to action here — but it is the layer that makes the working surfaces legible.
Constraints and boundaries
This page defines shared concepts at the system level. It does not replace surface-specific references, implementation notes, task instructions, or release communication.
Use this page for:
- Conceptual and model-level reference only.
- Cross-platform vocabulary the rest of the docs assume.
- Onboarding context for the platform's structural shape.
Use the per-surface Reference pages for:
- Specific surface ownership and module detail.
Use Guides for:
- Procedures and task execution.
Use What's New or Changelog for:
- Shipped changes.
Public boundary
This page is intentionally public-safe. It does not expose private infrastructure detail, internal credentials, exact network topology, unpublished operational controls, or protected service identifiers.
A reference list view in SG-Admin for the Shared Concepts module, shown at the Boundary surface. It lists the module name (Shared Concepts), its page slug (shared-concepts-index), and the surface it belongs to (Shared Concepts / Boundary).
Screenshot pending. This inline reference mock stands in for a captured screenshot of the Boundary view and will be replaced once the screenshot is available.
Examples
Example 1
A new operator reads Shared Concepts during onboarding
The new operator opens this page after Platform Overview, reads the Site Context vs Account Context section, and internalizes the boundary. When they next open SG-Dashboard and see one site card, the boundary explains why the site card opens into that site's own admin on a separate address from the dashboard. The vocabulary primes them for every other Reference page they will read.
Example 2
A support operator triages a "where did my change go?" ticket
The customer reports that a setting they changed at one surface did not propagate to another. The support operator opens this page's Surface Responsibility section, identifies the canonical surface for that setting, and walks the customer through where the edit should have happened. The shared model on this page resolves the ticket without escalating to engineering.
Example 3
An agency principal documents internal procedures against SGEN
The agency principal builds an internal SOP for their team's use of SGEN. They anchor the SOP on the vocabulary defined here — site context, account context, environment separation, ownership boundaries — so the SOP and the SGEN Reference library use the same words for the same things. The internal docs read alongside the SGEN docs without translation overhead.
Documentation guidance
Use this page as a stable Reference definition. Maintenance rules:
- Concept additions land alongside existing concept families, not as new top-level sections.
- When a concept appears on more than one Reference page, define it here and reference it from the per-surface pages rather than restating.
- The shape on this page should remain consistent across releases.
Vocabulary cross-reference
- Site context is the canonical phrase for the operating context inside one site's own admin. Body copy may shorten to "site-tier" where the prose flows.
- Account context is the canonical phrase for the operating context inside the SG-Dashboard account portal. Body copy may shorten to "account-tier" where the prose flows.
- Surface refers to a top-level operating environment (SG-Dashboard, SG-Builder).
- Pillar refers to a top-level grouping inside a surface (the admin's GENERAL, MODULES, STORE MANAGEMENT, CUSTOM OBJECTS, CONFIGURATION).
- Module refers to a single administrative or composition area inside a pillar (Pages, Blogs, Products, etc.).
- Tier refers to the scope of an operation (account-tier, site-tier, page-tier).
Reading order across the section
Open Shared Concepts (this page) once during onboarding, after Platform Overview. Internalize the concept families (surface responsibility, operating models, system relationships, reference continuity) and the key concepts (site context vs account context, environment separation, ownership boundaries, structured administration). Return to this page when terminology lands ambiguously somewhere downstream.
The page is short by intent. The platform does not need many shared concepts — only the small set that recur across surfaces. Adding a new shared concept is a structural decision, not a documentation expansion: a concept earns a place here when it appears across two or more surfaces and would otherwise be redefined inconsistently in each.
A reference list view in SG-Admin for the Shared Concepts module, shown at the Order surface. It lists the module name (Shared Concepts), its page slug (shared-concepts-index), and the surface it belongs to (Shared Concepts / Order).
Screenshot pending. This inline reference mock stands in for a captured screenshot of the Order view and will be replaced once the screenshot is available.
Where to find it
In SGEN Admin, Shared Concepts surfaces as the cross-platform vocabulary that every module and surface assumes. There is no dedicated Shared Concepts screen — the concepts apply across SG-Dashboard (account context), SG-Admin (site context), and SG-Builder (page context). Read this Reference before opening any per-surface or per-module page to carry the right vocabulary into those areas.
Where Shared Concepts appears on the live docs site
The Shared Concepts section on the live SGEN documentation site is a single Reference page — this one. It does not expand into sub-pages. The vocabulary defined here is referenced from the per-surface Reference pages and from the Guides, keeping the documentation legible without fragmenting the conceptual layer across many small entries.
Maintenance discipline
When a new platform feature lands, do not add a new shared concept by default. Check whether the feature fits inside an existing concept family first. Only add a new family entry when the feature defines a genuinely new cross-surface concept that would be redefined inconsistently elsewhere. The page stays valuable because it stays small.
The same discipline applies to renaming:
- A concept name on this page is the canonical name across docs, Guides, and any internal SOPs that anchor on the platform vocabulary.
- Renames here propagate downstream.
- Renames at a per-surface page that diverge from the vocabulary here create drift — revert them to align with this page, not the other way around.
When this page is the right first read
This page is the right first read when an operator, stakeholder, or documentation author needs the cross-platform vocabulary the rest of the SGEN Reference library uses.
It is not the right first read when:
- The question is about a specific surface — open that surface's Reference page instead.
- The question is about a procedure — open Guides instead.
The pairing across the Reference library is intentional:
| Read | Gives you |
|---|---|
| Platform Overview | System map |
| Shared Concepts (this page) | Platform vocabulary |
| Per-surface Reference (SG-Dashboard / SG-Builder) | Surface-level detail |
Reading the three in order gives a new reader the platform shape, the vocabulary, and the working surface coverage in roughly fifteen minutes.
Pairing with Architecture and Reliability
For readers who want the architectural reasoning behind the conceptual layer — why the platform separates surfaces the way it does, why environment separation is structural rather than procedural, why ownership boundaries hold under pressure — pair Shared Concepts with the Architecture and Reliability section.
The two pages complement each other:
- Shared Concepts — the operational vocabulary that follows from those structural decisions.
- Architecture and Reliability — the structural decisions themselves.
Documentation authors writing internal SOPs against SGEN often cite both pages to ground their team's vocabulary and architectural understanding in one place.