Environments and site states

In short. SGEN gives every site two environments — staging (internal review URL, safe to work in) and live (customer-facing domain, what end users see). Inside either environment, every record carries one of four states: draft (not visible at the public URL), published (visible), scheduled (auto-publishes at a set time), or archived (removed from public view, retained for recovery). Promotion is the governed operation that moves a record from staging to live. Every edit, review, and publish operation in SGEN is a move on this two-axis grid.

On this page: The two environments · The four states · How they combine · Promotion · Visibility rules · Examples · Vocabulary guard

This page is the shared vocabulary anchor — environment and state as defined here are the meaning behind "publish", "promote", "draft", "staging", and "live" across all other SGEN docs. For step-by-step procedures, open the relevant area Guide. Full detail: Publishing Model · Roles and Access · Shared Concepts Index.

Definition

An environment in SGEN is a full operating instance of a site that serves at a specific URL. SGEN provisions two environments per site by default — staging (internal review URL) and live (customer-facing domain). Both environments run on the same shared platform foundation; the difference is which URL each one answers, who sees it, and which records the platform treats as the public version.

A state in SGEN is the lifecycle position of a single record (a Page, Post, Product, Form, etc.) inside its environment. The state set is small and consistent across record types — draft (work in progress, not yet visible at the public URL), published (visible at the public URL of its environment), scheduled (set to publish at a future moment), and archived (removed from public visibility but retained for recovery and history).

Environment and state are the two coordinates that fully describe where any given record sits at any given moment. A "Page draft on staging" is not the same as a "Page draft on live" — same state word, different environment. A "Page published on live" is the only combination that ends up in front of an end user.

What an environment is

Going deeper: both environments are full operating instances of the site — not previews, not snapshots, not partial mirrors. Both run the same shared platform foundation: the same code path, the same module set, the same render pipeline. They differ only in which URL they answer, which set of records they treat as the public version, and who is expected to look at them.

Staging

Staging is the internal review environment. It serves at an internal URL that is not the customer-facing domain. It exists so that change can be authored, reviewed, and rehearsed before it reaches end users. Records published on staging are visible at the staging URL, to internal reviewers, but never to end users at the live URL.

Staging is a full environment. It runs the same modules, the same templates, the same render path. Its behavior is a complete rehearsal of live — not a stripped-down preview.

Live

Live is the customer-facing environment. It serves at the customer-facing domain — the URL end users visit. Records published on live are the ones end users see. Promoting from staging to live is the operation that moves content from internal-rehearsal status to public status.

Live is the only environment that end users ever interact with. It is also the environment whose behavior the platform's reliability disciplines are calibrated against — backups, audit trails, and recovery procedures all treat live as the production-of-record surface.

What a state is

A state describes the lifecycle position of a single record within an environment. The state set is small on purpose — there is no separate "queued", no separate "approved-but-not-published", no separate "in-review" state at the platform level. Editorial workflows on top of the state model can introduce review steps, but the underlying state of any given record is always one of the four documented here.

Draft

Draft is the working state. A draft record is being authored or revised. It exists in the record store, can be saved repeatedly without consequence to public visibility, and is not visible at the public URL of its environment. Drafts are how authoring happens — every published record passes through draft state at least once.

Published

Published is the visible state. A published record appears at the public URL of its environment. On staging, that means visible to internal reviewers at the staging URL. On live, that means visible to end users at the customer-facing domain.

Scheduled

Scheduled is a deferred-publish state. A scheduled record is set to transition to published at a specific future moment in its environment. The platform handles the transition automatically — operators do not need to be present at the scheduled moment for the publish to happen.

Archived

Archived is the removed-from-public state with retention. An archived record is no longer visible at the public URL of its environment, but it is retained in the record store and remains visible inside the administrative surface. Archive is structurally different from delete — archive preserves the record, delete removes it.

How environment and state combine

Environment and state are independent coordinates. A record always has both, and the combination is what determines its actual visibility. Saying a record is "published" is incomplete — it is published somewhere. The two-axis grid below covers the meaningful combinations operators encounter day to day.

A record that is draft on staging is not visible anywhere except inside the admin record list. A record that is published on staging is visible at the staging URL but not the live URL. A record that is published on live is the only state that puts the record in front of end users.

The platform tracks state per environment. A record can be at one state on staging and a different state on live — for example, an updated version published on staging while the old version remains published on live, until promotion happens.

Promotion from staging to live

Promotion is the operation that takes a record (or a set of records) from one environment into another. In SGEN, promotion is governed — it is not a manual file copy, not a database export, not a third-party orchestration. The platform owns the promotion surface and the audit trail.

The model is staging-then-live by default. Operators author and review on staging. When the change is ready, promotion publishes the staging version into live, where it becomes the visible record at the customer-facing domain. The previous live version is preserved in the record store, available through the platform's recovery surface.

Promotion is per-record at the platform level — operators can promote a single Page, a single Post, a single Product, or any structured grouping the platform supports. Bulk promotion (an entire site, an entire content section) is available through dedicated operations rather than through the per-record surface.

Where each environment is visible

Visibility is the most common source of confusion when operators first work with SGEN, especially when they are arriving from a single-environment CMS background. The rules below are the ones that hold across every record type and every module.

• Staging URL → published-on-staging records. End users do not visit this URL. Internal reviewers, content authors, and approvers do.
• Live URL (customer-facing domain) → published-on-live records. This is what end users see. Records that are draft, scheduled, or archived on live are not present at this URL.
• SG-Admin record list → every record regardless of environment or state. The administrative surface shows everything that exists in the record store, with state and environment annotations next to each record. The record list is where authoring and review happen.
• SG-Dashboard environment switcher → both environments per site, listed at the account tier. The Dashboard surfaces "this site has staging and live" as part of the per-site row.

End users never see staging. End users only see what is published on live. Internal reviewers see staging when they visit the staging URL or when they look at the admin record list with the staging filter active.

Constraints and boundaries

Some properties of the environment-and-state model are structural and worth naming explicitly so operators do not assume otherwise.

• Environment count is fixed at two per site. Staging and live. SGEN does not provision arbitrary numbers of environments per site at the operator tier. If a workflow needs an extra rehearsal layer, the platform's per-record draft-and-promotion surface covers that — additional environments are not the right tool.
• State set is fixed at four. Draft, published, scheduled, archived. The platform does not surface a generic per-record "approved but not published" state at this layer; editorial review is layered on top of state, not as a state.
• Records exist independently per environment. A record can be at one state on staging and a different state on live. Promotion is the operation that reconciles them.
• Delete is structurally different from archive. Archive preserves the record. Delete removes it. Recovery surface treats them differently.
• Promotion preserves the prior live version. The previous live record is retained in the record store and accessible through the recovery surface — operators do not lose the prior version when they promote.

Examples

Example 1 — A new operator publishes their first Page

A new content author opens the admin, creates a new Page, and types into the editor. Save creates a Page record in draft state on staging by default. The author refines, saves repeatedly (drafts can be saved freely without affecting public visibility), and clicks Publish. Now the record is published on staging, visible at the staging URL. The author asks the team lead to review at the staging URL. The lead approves. The team lead promotes the Page from staging to live. The record is now published on live, visible at the customer-facing domain to end users. The previous (empty) live state of that Page slug is preserved in the record store.

Example 2 — A scheduled blog post

A marketing operator drafts a Post during the workweek and wants it to publish at 09:00 on Monday. They save the draft on staging, set it to scheduled on staging at 09:00 Monday, review the staging URL preview, and promote the scheduled record to live. The platform now holds a scheduled-on-live Post that will auto-transition to published-on-live at 09:00 Monday. No one needs to be present at 09:00 for the publish to happen. The platform owns the transition.

Example 3 — Reviewing a change that is "live on staging but not live on live"

An operator is asked "is the new pricing page live yet?" They check the live URL — it shows the old page. They check the staging URL — it shows the new page. They check SG-Admin — the new Page record is published on staging, the old Page record is published on live. The change has been authored and rehearsed but not promoted yet. The operator either promotes (to ship the new version) or asks the author to confirm before promoting.

Example 4 — Archiving a campaign page after the campaign ends

A holiday-campaign Landing Page is published on live during the campaign window. After the campaign, the operator archives it. The page is now archived on live — it is no longer at the customer-facing URL, but it is still in the record store, available to revive next year by transitioning back to draft and re-publishing. Nothing is lost; visibility is removed.

Example 5 — A record that exists on staging but never made it to live

An author drafts a page on staging, publishes it on staging for review, the team decides not to ship it. The record sits published on staging, not present on live. End users never see it. The operator can either delete it (removes from record store) or leave it on staging as historical reference. Either choice is structural — there is no penalty for an unfinished staging-only record other than housekeeping noise on the record list.

Example 6 — A scheduled publish that needs to be rolled back

A scheduled Post is set to publish at 14:00. At 13:55, the author realizes the headline has a typo. They edit the scheduled record back to draft state, fix the typo, and either re-schedule or publish immediately. The state model lets the scheduled record be modified or canceled before its trigger fires.

Related reading

New to SGEN? This page is the foundation of the Shared Concepts pillar — environment and state are the two coordinates every other concept page builds on. Continue with: Publishing Model (lifecycle), Roles and Access (permissions).

• Publishing Model — the lifecycle that records pass through.
• Roles and Access — who can save, publish, promote in each environment.
• Shared Concepts Index — sibling concept pages.
• SG-Dashboard Overview — the account-tier surface where staging and live are listed per site.
• SG-Admin Overview — the per-site surface where authoring and publishing happen.
• Migration and Import Overview — environment promotion in the migration context.
• Welcome to SGEN Docs — start-here landing.

Vocabulary cross-reference

• Environment — full operating instance of a site at a specific URL (staging or live).
• State — lifecycle position of a record within an environment (draft, published, scheduled, archived).
• Promotion — the governed operation that moves a record from staging to live.
• Publish — transition a record to the published state in its current environment.
• Schedule — set a record to publish at a future moment in its current environment.
• Archive — remove a record from public visibility while keeping it in the record store.
• Customer-facing domain — the URL end users visit; only live serves at this URL.
• Staging URL — the internal review URL; only staging serves at this URL.
• Per-environment — a property or behavior that exists separately for staging and live; the two values are independent.
• Per-record — a property or behavior that exists separately for each record; siblings under the same module can be at different states.
• Record store — the platform-managed storage that holds every record across all states; archive and delete differ in whether the record stays in the record store.
• Recovery surface — the platform's exposed surface for restoring prior versions of a record; promotion always preserves the prior live version into this surface.
• End user — the public visitor at the customer-facing domain; never sees staging.
• Internal reviewer — an operator with access to the staging URL or to the admin; sees both staging and live.