Environments and Site States

Field	Value
Audience	public
Page type	reference
Area	shared-concepts
Updated	2026-05-14
What this covers
---
What is this for?
Good use cases
What NOT to use this for
How this connects to other features
Definition
Purpose
Scope
What an environment is
What a state is
How environment and state combine

How SGEN models environments and per-record states — the mental model behind every edit, review, and publish.

SGEN exposes two environments per site (staging and live) and a small set of per-record states (draft, published, scheduled) that describe where a record sits in its lifecycle. This page is the shared definition of how those two layers fit together — environment is where the site lives, state is what each record is doing inside that environment.

This is a foundational shared concept. Every editing, review, and release operation a SGEN operator runs touches it. Saving a draft, scheduling a post, promoting a change to live, reviewing a change before it ships, comparing what staging shows against what live serves — every one of those routes through the environment-and-state model documented here.

What is this for?

Read this page when you want the shared mental model behind environments and per-record states in SGEN. It defines what staging and live are, how they relate, what each per-record state means, where the boundary between environment and state sits, and how all of that affects the editing and publishing operations operators run every day.

The page is a Reference definition. It does not walk you through publishing a specific post or promoting a specific change — those procedures live in Guides. It also does not describe operational mechanics like backup or rollback in detail; those have their own Reference pages under Migration and Import.

Good use cases

• You are new to SGEN and want the staging-vs-live model explained in operator language before you click anything.
• You are returning from another CMS where "staging" meant something different (a preview iframe, a dev plugin, a manual database copy) and want to know what SGEN means by the word.
• You are scoping a content workflow and need to know which states a record passes through and which environment surfaces it appears in.
• You are reviewing a change someone else made and want to confirm where you should be looking — the staging URL, the live URL, the admin record list, or the publish queue.
• You hit an "I edited it but it's not live yet" or "it's draft on staging but not on live" question and want the structural model that explains why.

What NOT to use this for

• Step-by-step procedures for publishing a record — open the relevant Guide.
• Rollback or recovery procedures — open Recovery Considerations Reference.
• Per-area module behavior (how Pages publish, how Products go live, how Forms route) — open the relevant area Reference page.
• Per-release behavior change — open What's New or Changelog.

How this connects to other features

• Publishing Model — the lifecycle that records pass through inside an environment.
• Roles and Access — who can save, publish, and promote inside each environment.
• Shared Concepts Index — sibling concept pages.
• SG-Dashboard Overview — the account-tier surface where the per-site environment list is visible.
• SG-Admin Overview — the per-site administrative surface where staging and live are operated.

---

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.

Purpose

The purpose of this page is to give operators a shared model for environment and state, so that every editing, reviewing, scheduling, and publishing conversation in SGEN can use the same vocabulary and expect the same behavior. Without that shared model, "live" gets confused with "saved", "draft" gets confused with "unpublished but visible", and "staging" gets confused with "preview." The model below makes those distinctions concrete.

Scope

This page covers the environment-and-state model at the shared-concept level — the structure rather than the procedure.

The page covers:

• The definition of environment in SGEN (staging and live).
• The definition of state for a record (draft, published, scheduled, archived).
• The relationship between environment and state.
• The visibility rules (what is visible at what URL, to whom).
• The promotion model that moves change from staging to live.
• The boundary against module-specific publishing behavior, against rollback procedures, and against per-record editing mechanics.

The page does not cover:

• Per-area publishing mechanics (how Pages publish, how Products go live) — open the relevant area Reference page.
• Rollback or restore procedures — open Recovery Considerations.
• Permission rules for who can save, publish, and promote — open Roles and Access.
• Per-release shipped behavior change — open What's New or Changelog.

---

What an environment is

A SGEN environment is a full operating instance of the site, not a preview, not a snapshot, not a partial mirror. Both environments 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 at, 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 the rehearsal of the live behavior, 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. Promotion of change from staging to live is the operation that takes change 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.

---

Documentation guidance

This page is the shared definition of environment and state. Use it as the vocabulary anchor when other Guides reference "publishing", "promoting", "scheduling", "draft", "live", "staging", or "archived" — the meanings are the ones defined here.

For step-by-step procedures (how to publish a Page, how to schedule a Post, how to promote, how to archive), open the relevant area Guide. For the broader publishing lifecycle that sits on top of state, open the Publishing Model. For permission rules around who can publish or promote in each environment, open Roles and Access.

Reading order

If you are new to SGEN, read this page first among the Shared Concepts pillar — environment and state are the foundation that the other shared-concept pages build on. After this page, the Publishing Model expands the lifecycle view, and Roles and Access adds the permission view.

If you arrived here from a per-area Guide (Pages, Posts, Products), this page is the cross-reference that explains the publish and promote terminology that Guide uses.

Related reading

• 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.

Related reading

Topic
Publishing Model
Roles and Access
Shared Concepts
Welcome to SGEN Docs
SG-Dashboard
SG-Admin