Shared Concepts

Five pages, one operating model — read these before any per-area Guide.

Shared Concepts is the platform-tier operating model that every per-area Guide and every per-area Reference assumes. Five pages live in this section. Together they describe how SGEN's environment-and-state model, publishing model, roles-and-access model, data-and-tracking model, and integrations model fit into a single, coherent way of working with the platform.

This page is the entry point. It tells you which sibling page answers which question, the order to read them in, and the vocabulary that holds across all five.

What is this for?

Read this page when you want to find the right shared-concept page quickly and read the pillar in the order that builds the model coherently. The page is shorter than each sibling — its job is to orient, link, and define the cross-cutting vocabulary, not to re-explain what the siblings define.

The page is an index. It does not duplicate the content of the sibling pages. It points to them.

Good use cases

• You are new to SGEN and want to see the full pillar at a glance before deciding what to read first.
• You hit a question and you are not sure which shared-concept page covers it.
• You want the recommended reading order so the model builds correctly in your head.
• You are sending a stakeholder to read the pillar and want a single link to share.
• You are referencing the pillar from another doc and want a stable index entry to link to.

What NOT to use this for

• Definitions of environment, state, publishing, role, capture, or integration — those live in the sibling pages.
• Step-by-step procedures — those live in per-area Guides.
• Per-area Reference (Pages, Posts, Products, Forms) — open the relevant area page.
• Per-release shipped behavior change — open What's New or Changelog.

How this connects to other features

• Each sibling page in this pillar is linked below in reading order.
• The pillar as a whole is assumed by every per-area Reference and every per-area Guide elsewhere on the docs site.
• This page links forward into Architecture (the platform-architecture-overview page) and SG-Dashboard / SG-Builder Reference, where the surfaces these concepts apply to are detailed.

---

Definition

The Shared Concepts pillar is the set of platform-tier operating-model pages that every other docs page assumes a reader has internalized. The pillar has five canonical entries:

1. Environments and Site States — where and what state.
2. Publishing Model — what operations move records between (where, state) coordinates.
3. Roles and Access — who is permitted to run those operations.
4. Data and Tracking Model — what the platform captures from the site and surfaces back.
5. Integrations Model — how external services connect into the captured-and-surfaced flow.

Read in this order, the model builds: coordinates first, operations second, permissions third, captured data fourth, integrations last. Reading out of order is possible but increases the chance of hitting a forward reference that needs an earlier page to make sense.

Purpose

The purpose of this index is to make the pillar discoverable and to anchor the reading order. Without an index, a reader landing on a sibling page might not realize there are four others that complete the model. With this index, the pillar becomes a coherent whole that can be entered from any direction and walked in a useful order.

Scope

This page covers the pillar at the index level — the orientation rather than the model itself.

The page covers:

• The five sibling pages and what each one defines.
• The recommended reading order.
• The cross-cutting vocabulary that holds across the pillar.
• The boundary against per-area Reference and per-area Guides.

The page does not cover:

• The definitions inside each sibling page — those are in the sibling pages.
• Per-area procedural Guides — those live in the relevant area.
• Architecture-tier framing — that is in the Architecture pages.

---

Sibling pages — what each one is for

Environments and Site States

The where-and-what-state coordinates. Defines staging vs live (the two environments) and draft / published / scheduled / archived (the four states a record can be in). Every other shared-concept page assumes this coordinate model. Read this first.

Publishing Model

The operations that move records between (environment, state) coordinates. Defines save (persist working version), publish (transition to published in current environment), and promote (move from staging to live). Names the audit and recovery discipline that runs underneath every publish event.

Roles and Access

The permission model. Defines the two-tier authority structure (account-tier at SG-Dashboard, site-tier at SG-Admin) and the role catalog at each tier. Account-tier authority does not auto-grant site-tier authority — the model is structured so multi-site accounts stay compartmentalized.

Data and Tracking Model

The capture-and-surfacing model. Defines the five capture surfaces (Forms, Analytics, Phone Taps, Events, Discussions), the consent and retention discipline that runs underneath, and the three surfacing mechanisms (per-module record list, exports, downstream integrations).

Integrations Model

The connector model. Defines how SGEN connects to external services through first-party connectors that ship with the platform, are configured per-site, audited per change, and updated on the platform release cadence rather than a per-vendor schedule.

---

Cross-cutting vocabulary

A few terms come up across multiple sibling pages. Treat their definitions as canonical across the pillar.

Environment

Staging or live — the full operating instance of a site at a specific URL. Defined in Environments and Site States. Used by Publishing (per-environment publish), Roles (per-environment authorities are not the default model — site-tier roles span both environments by default), Data and Tracking (capture is per-environment), and Integrations (connectors can be configured per environment).

State

Draft / published / scheduled / archived — the lifecycle position of a record within its environment. Defined in Environments and Site States. Used by Publishing (operations transition state) and Data and Tracking (captured records have their own platform-managed states distinct from content states).

Audit signature

The platform-managed record of a change-affecting operation: operator + timestamp + record + change. Same shape across Publishing, Roles, Data and Tracking, and Integrations. The unified audit surface is what lets a single query correlate events across pillars.

Per-site scoping

The principle that operations and configuration are scoped to a single site by default; cross-site sharing is not the implicit model. Used in Roles (site roles are per-site), Data and Tracking (captured records belong to one site), and Integrations (connector instances are per-site).

Platform-managed

The principle that the platform owns implementation, runtime, and release for the named concern. Used in Publishing (audit, retention, recovery), Data and Tracking (capture, governance), and Integrations (connector code, credentials, health).

---

Examples

Example 1 — A new operator works the pillar in order

A new operator has joined the team. They open Welcome to SGEN Docs, follow the Start Here pillar, and arrive at this index. They read the five sibling pages in order — environments first, publishing second, roles third, data fourth, integrations fifth. By the end, they understand what staging vs live means, what publish does, what their role permits, what the platform captures, and how the CRM connector is configured. They can now open any per-area Guide and follow it without backfilling vocabulary.

Example 2 — A returning operator hits a question and uses the index

An operator who knows SGEN well returns from a quarter away. They hit a "the connector is not firing" question. They open this index, see Integrations Model in the question-to-page mapping, open it, and find the failure-handling section. The index saved them a search-and-scroll and got them to the right page in one click.

Example 3 — A stakeholder reads only the index

A stakeholder reviewing SGEN's operating posture reads this index but not the sibling pages. They walk away with the structural shape of the model — the five layers and the cross-cutting vocabulary — without committing to the detail of each sibling. The index provides enough orientation for a stakeholder-level conversation; for operator-level work, the sibling pages are still required reading.

Example 4 — A docs writer linking to the pillar

A docs writer authoring a per-area Reference page wants to send the reader to the shared-concept pillar. They link to this index instead of linking to one specific sibling, because the per-area page touches multiple shared concepts. The reader lands on the index, sees the five pages, and picks the one that applies to their immediate question.

Example 5 — Re-reading the pillar after a behavior change

A platform release lands that adjusts the publish model. The operator opens the index, sees Publishing Model called out as the page covering the model, opens it, reads the relevant section. The index makes the re-read targeted rather than a full pillar re-read.

Example 6 — Onboarding a partner agency

A partner agency starts working on a SGEN account for their client. The principal sends two links to the agency team: this index and the home page. The agency reads through the pillar in order, internalizes the operating model, and arrives at per-area Guides ready to operate without backfilling. Onboarding without this pillar would have taken longer and produced more "why does the platform behave this way" questions.

Example 7 — Aligning vocabulary across teams

A technical writer for the operator's internal documentation wants to write SOPs that cite SGEN's vocabulary correctly. They use this pillar as the canonical vocabulary source. Their SOPs use "promote" the way SGEN defines it, "publish" the way SGEN defines it, "site-tier role" the way SGEN defines it. Cross-team conversations stay aligned because everyone is reading the same five pages.

---

Documentation guidance

This page is the index for the Shared Concepts pillar. Use it to navigate to the right sibling page, to find cross-cutting vocabulary, and to share the pillar as a single entry point.

For step-by-step procedures, open the per-area Guide that applies. For the model definitions themselves, open the sibling page named in the index. For Architecture-tier framing (how the platform is built, not how it operates), open the Architecture pillar.

Reading order

The recommended order is the order this index lists the siblings in: environments → publishing → roles → data → integrations. Reading out of order is possible, but each sibling assumes the earlier ones, so out-of-order reading sometimes means following a forward reference back to an earlier page.

Related reading

• Environments and Site States — read first.
• Publishing Model — read second.
• Roles and Access — read third.
• Data and Tracking Model — read fourth.
• Integrations Model — read fifth.
• Welcome to SGEN Docs — start-here landing.
• Home — top-level entry point to the docs.

Vocabulary cross-reference

• Pillar — a coherent set of docs pages that together describe one operating concern; Shared Concepts is one pillar.
• Index page — the entry-point page that orients the reader to a pillar and lists the siblings in reading order.
• Sibling page — one of the canonical entries inside a pillar (each shared-concept page is a sibling to the others).
• Reading order — the recommended sequence for working through a pillar; assumed by sibling pages that reference earlier siblings.
• Cross-cutting vocabulary — terms that appear across multiple siblings with the same canonical meaning.
• Operating model — the platform-tier model the pillar describes; assumed by every per-area Guide and per-area Reference elsewhere on the docs.
• Per-area Reference — pages that describe specific platform areas (Pages, Posts, Products, Forms, etc.) and assume the shared-concepts model.
• Per-area Guide — step-by-step procedures inside a specific area; references but does not re-explain the shared-concepts model.
• Question-to-page mapping — the index's table that helps a reader locate the right sibling by the question they are asking.
• Forward reference — a sibling page mentioning a concept defined in a later sibling; reading in order minimizes these.
• Stable index entry — this page; intended to remain at a stable URL so external docs and internal references can link to it without breaking.
• Pillar-as-a-whole — the five siblings considered as one operating-model unit, the way other docs reference them.
• Pillar exit — the recommended next docs surface to read after completing the pillar; varies by reader goal.
• Operator-tier vocabulary — the canonical terms the pillar establishes for use by every other docs page.
• Per-customer override — a permission, retention, or integration arrangement that sits outside the platform-defined defaults; negotiated through the customer agreement, mentioned in sibling pages where relevant.
• Reading depth — how thoroughly a reader works the pillar; stakeholder reads may stop at this index, operator reads should cover all five siblings.
• Vocabulary anchor — the role this index plays for cross-cutting terms that appear in multiple siblings; the index is the canonical lookup.
• Operating concern — a single coherent platform behavior that one pillar describes; Shared Concepts is the operating-concern pillar.
• Architecture pillar — the parallel pillar that describes how the platform is built (vs. how it operates); Architecture sits alongside Shared Concepts in the docs structure.
• Per-area Reference pillar — the docs surface that describes specific platform areas (SG-Dashboard, SG-Builder); assumes Shared Concepts.
• Guides surface — step-by-step procedural docs inside an area; references Shared Concepts but does not re-derive it.
• External link target — this page's role for partner agencies, contractors, or external reviewers who need a single shareable entry point to the pillar.
• Search anchor — the role of cross-cutting vocabulary terms in helping a reader find the right sibling page through full-text search.
• Pillar-update propagation — when a sibling page changes, this index's vocabulary cross-reference may need a parallel update; the audit trail of the index records when that propagation happened.
• Stable URL — the property of this index that lets external references and internal cross-links remain valid even as siblings are updated.
• Pillar entrypoint — this page; the canonical start of the Shared Concepts pillar.
• Sibling cross-reference — a link from one sibling page to another within the pillar, used when one model touches another.
• Per-area dependency — the way per-area Reference and Guides depend on Shared Concepts; per-area pages do not re-derive the model, they cite it.
• Stakeholder read — a shorter read of the pillar that may consist of this index page; sufficient for high-level operating-posture conversations.
• Operator read — the full pillar read; required for operators who will run Save / Publish / Promote / configure connectors / manage roles.
• Vocabulary reconciliation — the periodic check that vocabulary used across siblings remains aligned; this index's cross-reference table is the canonical source for that check.
• Pillar version — the joint version of the five siblings as voice-rewritten on the same date; documented in each sibling's frontmatter status field.
• Re-entry point — the role this index plays for an operator returning to the pillar after a behavior change; the question-to-page mapping speeds the re-entry.
• Pillar audit — the platform-managed record of when each sibling was last updated; queryable through the docs-tree refresh and the auto-updater rollup.
• Cross-pillar reference — a link from this pillar to Architecture or to per-area Reference; appears in the Pillar exit map for goal-driven navigation.
• Default reading depth — the recommended depth for a new operator: full pillar in order, then per-area Guide for the immediate task.
• Vocabulary halo — the set of terms a sibling page uses without re-defining; the halo is what this index resolves for a reader.
• Operator continuity — the property of the pillar that lets an operator returning after time away regain the operating-model context quickly via the index.
• Pillar coherence — the property that the five siblings share the same canonical vocabulary so the model holds together when read as a single sequence.
• Index integrity — the property that this page lists every sibling and only links to canonical sibling URLs; verified at each pillar update.
• Cross-team alignment — the use of this pillar as the shared vocabulary across operators, content authors, technical writers, and stakeholders inside the customer organization.
• Pillar growth — the path for adding a sixth shared concept if one is discovered; would require a new sibling page plus an update to this index, with both audited.
• Pillar deprecation — the path for retiring a shared concept that no longer applies; would require sibling-page archival plus an update to this index.