Publishing Model

How change moves from edit to published in SGEN — the lifecycle and the platform discipline underneath.

SGEN's publishing model is the lifecycle a record passes through to become visible at the public URL of its environment, plus the operations operators run on that lifecycle, plus the audit and recovery posture the platform maintains underneath. This page is the shared definition of how publishing works at the platform level, common across every record type — Pages, Posts, Products, Forms, Custom Objects, Locations, Events, and the rest.

This page sits next to Environments and Site States. The two pages cover the same operating territory from two angles: environments-and-states defines the where and what state coordinates; this page defines the operations that move a record between coordinates and the discipline that runs underneath those operations.

What is this for?

Read this page when you want the shared model behind every publishing operation in SGEN. It defines what save means, what publish means, what promote means, how those three operations relate to each other, what the platform records every time one runs, and how the audit and recovery posture sits underneath. It is meant to be the vocabulary anchor for every Guide that mentions publishing.

The page is a Reference definition. It does not walk you through publishing a specific record type — those procedures live in per-area Guides. It also does not enumerate per-customer rate limits or operational SLAs; those live in versioned reference and in the customer agreement.

Good use cases

• You are new to SGEN and want the publishing vocabulary explained before you click anything that says "Publish."
• You are returning from a CMS where save and publish were the same button, and want to know how SGEN separates them.
• You are scoping an editorial workflow and need to know what the platform tracks per publish event.
• You are designing an internal review process and want to know which platform operations carry an audit signature.
• You are working through a recovery scenario and need to know what the platform retains per record across publish events.
• You hit a "the change disappeared / the change is on staging but not on live" question and want the structural model that explains the difference.

What NOT to use this for

• Step-by-step procedures for publishing a specific record — open the relevant area Guide.
• Per-area module behavior (Pages publish details, Posts schedule details, Products go-live details) — open the relevant area Reference page.
• Recovery procedures or restore walkthroughs — open Recovery Considerations Reference.
• Per-release shipped behavior change — open What's New or Changelog.

How this connects to other features

• Environments and Site States — the where-and-what-state coordinates that this page's operations move records between.
• Roles and Access — who is permitted to save, publish, and promote.
• Shared Concepts Index — sibling concept pages.
• SG-Admin Overview — the per-site administrative surface where save / publish / promote operations are exposed.
• Backups — the safeguard that protects every publish event.

Definition

The publishing model in SGEN is the set of operations and lifecycle rules that govern how a record becomes visible at the public URL of its environment, plus the audit and recovery discipline the platform runs underneath those operations.

The model has three operator-facing operations — save, publish, promote — and one underlying discipline — audit and retention — that the platform runs for every record passage through the lifecycle. Operators do not configure the audit discipline; it is part of the platform's operating posture.

Save persists work. Publish transitions visibility. Promote moves a record between environments. Each operation is governed, audited, and reversible to the extent the lifecycle allows.

Purpose

The purpose of this page is to give operators a stable, shared model of publishing so that every per-area Guide and every operational conversation can use the same vocabulary and expect the same behavior. Without that shared model, "save" gets confused with "publish" (and operators wonder why their changes are not live), "publish" gets confused with "promote" (and changes appear on staging but never make it to live), and "audit" becomes invisible (and operators do not realize how much the platform retains for them).

Scope

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

The page covers:

• The definition of save, publish, and promote as operations.
• The lifecycle a record passes through across those operations.
• The audit-trail discipline the platform records for each operation.
• The retention discipline that protects prior versions.
• The boundary against per-area publishing mechanics and against rollback procedures.

• Per-area publishing procedures — open the relevant area Guide.
• Permission rules for who can publish — open Roles and Access.
• Backup, restore, or recovery procedures — open Backups and Recovery Considerations.
• Per-release shipped behavior change — open What's New or Changelog.

Save

Save persists the working version of a record. The working version is the in-progress draft that an operator is editing — the one that may not be ready for public visibility. Save is the lower-cost, lowest-stakes operation in the model: operators are encouraged to save freely as they work.

Save does not change public visibility. A saved draft remains in draft state. The save operation only updates what the platform stores as the working version of the record, ready to be picked up the next time the operator returns to the editor.

Save is per-environment in the sense that the working version belongs to the environment the operator is currently editing in. Saving on staging persists the staging working version; saving on live persists the live working version. The platform does not silently cross environments on save.

Publish

Publish transitions a record to published state in its current environment. A published record appears at the public URL of that environment — the staging URL if publishing on staging, the customer-facing domain if publishing on live. Publish is the operation that converts working state into visible state.

Publish is governed. The platform records who published, when, what the record looked like at the moment of publish, and what state it transitioned from. The published version becomes the canonical "this is what is at the public URL right now" version of the record, until a subsequent publish or unpublish operation changes it.

Publish is reversible. The platform's recovery surface retains prior published versions, so an operator who needs to roll back a published change can return to a prior version through a recovery operation rather than rebuilding the prior content from memory.

Promote

Promote is the operation that moves a record across environments — from staging to live by default. Promote is the only one of the three operations that crosses an environment boundary. It is structurally heavier than save or publish because it changes what end users see at the customer-facing domain.

Promote takes the staging version of a record and writes it as the live version. The previous live version is preserved through the platform's retention discipline and remains accessible through the recovery surface. Promotion is per-record at the platform level — operators can promote one Page, one Post, one Product, or any structured grouping the platform supports.

Promote is governed. Like publish, the platform records who promoted, when, what the record looked like at the moment of promotion, and what the prior live version looked like. The audit signature on a promote event is the strongest of the three operations because it changes end-user visibility.

Audit and retention discipline

Every save, publish, and promote operation in SGEN goes through a platform-managed audit and retention layer. Operators do not configure this layer per record or per site at the operator tier — it is part of the platform's operating posture, available by default for every record across every module.

Audit signature

For each publish and promote operation, the platform records who ran the operation, when it ran, what record it acted on, and what the record state was at the moment of the operation. The audit signature is what supports operator review, change-control conversations, and the audit-readiness posture the platform commits to.

Prior-version retention

For each publish or promote operation that changes a record, the platform retains the prior published version so that recovery is possible without operator-side data engineering. Operators do not have to copy a record before publishing in order to be able to roll back; the platform does that retention as part of the publish event.

Backup coverage

The publishing model sits inside the platform's backup discipline. Backups capture the record store including all states (draft, published, scheduled, archived) and the audit trail attached to them. Recovery from a backup restores the record store including the audit context that was current at the moment the backup was captured.

Recovery surface

When a recovery operation is needed, the platform exposes a surface for restoring prior versions. The surface is reachable through the per-site administrative surface and is the operator-tier entry point for what would otherwise be database-tier work on other platforms.

Audit-signature contents per operation

The audit signature is consistent in shape across operations, but the semantic weight differs. A save event records persistence. A publish event records a visibility transition in one environment. A promote event records a visibility transition that crosses an environment boundary and changes what end users see. Operators looking at the audit trail can read the operation type and immediately know whether end-user visibility was affected.

The audit signature is queryable through the platform's administrative surface. Operators can ask "what published last Tuesday on this Page?" or "who promoted this Product to live?" and get an answer without leaving the platform or stitching together logs from external systems.

Constraints and boundaries

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

• Save and publish are separate operations. SGEN does not collapse them into a single button by default. Save persists working state; publish transitions visibility.
• Publish is per-environment. Publishing on staging makes the record visible at the staging URL only. Publishing on live makes it visible at the customer-facing domain. There is no "publish to both" shortcut at the operator tier; that is what promote is for.
• Promote crosses an environment boundary. It is the only operation in this model that does. Treat promote as the heavier operation — the audit signature is stronger and the recovery posture engages more deeply.
• Schedule is a time-deferred publish, not a separate operation kind. A scheduled record transitions to published in its environment at the scheduled moment. The platform owns the transition.
• Archive removes from public visibility but preserves the record. It is structurally different from delete, which removes from the record store entirely. Recovery treats them differently.
• Per-record granularity is the default. Bulk operations (publish many at once, promote a section, archive a campaign) are exposed as dedicated bulk surfaces rather than as side-effects of per-record operations.

Examples

Example 1 — A first publish that lands at the live URL

A new content author opens the admin, creates a Page, types into the editor, clicks Save several times as they refine the copy. The Page is in draft on staging. They click Publish. The Page transitions to published on staging — visible at the staging URL but not the live URL. The team lead reviews, approves, and runs Promote. The Page is now published on live — end users see it at the customer-facing domain. The audit trail records every save, every publish, and the promote operation, with operator identity and timestamps.

Example 2 — A change that needs to be reverted after going live

A Post was promoted to live with a wrong screenshot. The operator opens the Post, opens the Recovery surface, selects the prior published version (the one before the bad promote), and restores it as the live version. The platform's prior-version retention made the rollback possible without database-tier engineering. The audit trail records the rollback with operator identity and timestamp, sitting next to the original promote event.

Example 3 — A scheduled publish that auto-fires

A marketing operator finishes a Post on Friday afternoon, schedules it on staging for 09:00 Monday, reviews the staging URL preview, and promotes the scheduled record to live. The platform now holds a scheduled-on-live Post that will transition to published-on-live at 09:00 Monday automatically. The operator does not need to be present at 09:00. The audit trail records the auto-transition as it would record a manual publish.

Example 4 — Why a save did not become visible

An operator is asked "did you publish that?" They check the live URL — old version. They check the staging URL — also old version. They check SG-Admin — the record shows they saved an updated version, but the published version is still the old one. They forgot to publish after saving. They click Publish on staging, review, then promote to live. Now the new version is visible at the customer-facing domain. The operator's save events are in the audit trail, distinct from the publish event that finally changed visibility.

Example 5 — A bulk archive at the end of a campaign

A campaign ends. The operator opens the admin, filters the Page list to the campaign tag, selects the campaign Pages, and runs the bulk Archive operation. Every campaign Page transitions from published on live to archived on live. The customer-facing domain no longer serves them. The Pages remain in the record store and could be revived next year. The audit trail records the bulk operation as a single archive event with the affected record list.

Example 6 — Auditing a change that did not look right

A stakeholder asks "who changed the pricing block last Tuesday?" The operator opens the audit trail for the Page, filters by the relevant date, finds the publish event with the operator identity, and answers the question without leaving the platform. No external log aggregation is needed; the audit signature is part of the publishing model.

Example 7 — A scheduled publish that needs to be canceled

A scheduled Post is set to publish at 14:00. At 13:55, the author realizes the headline has a typo. They open the scheduled record, transition it back to draft state, fix the typo, and either re-schedule or publish immediately. The platform records the cancel-and-rewrite as a sequence of operations in the audit trail rather than collapsing it into a single edit, so reviewers can see the timeline of what changed and when. The originally scheduled trigger is canceled and does not fire.

Example 8 — Bulk promote at the end of an editorial sprint

An editorial team finishes a sprint with twelve Posts ready on staging. Rather than promoting them one at a time, the operator opens the admin, selects the twelve Posts, and runs the bulk Promote operation. Each Post transitions from published on staging to published on live. The audit trail records a single bulk-promote event with the affected record list and the operator identity. The customer-facing domain now serves all twelve.

Documentation guidance

This page is the shared definition of publishing. Use it as the vocabulary anchor when other Guides reference "save", "publish", "promote", "audit", "recovery", or "rollback". Per-area Guides describe how those operations are exposed inside specific modules; this page describes what the operations are and what discipline runs underneath.

For step-by-step procedures (how to publish a Page, how to promote a Product, how to schedule a Post, how to recover a prior version), open the relevant area Guide. For the environment and state coordinates the operations move records between, open Environments and Site States. For who is permitted to run each operation, open Roles and Access.

Reading order

If you are new to SGEN, read Environments and Site States first, then this page. The two together form the operating model that every other Guide assumes. After this page, Roles and Access adds the permission layer.

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

Related reading

• Environments and Site States — the where-and-state coordinates the operations move records between.
• Roles and Access — who can save, publish, promote in each environment.
• Shared Concepts Index — sibling concept pages.
• SG-Admin Overview — where save / publish / promote operations are exposed per site.
• Backups — the safeguard underneath every publish event.
• Welcome to SGEN Docs — start-here landing.

Vocabulary cross-reference

• Save — persist the working version of a record; no public visibility change.
• Publish — transition a record to published state in its current environment.
• Promote — move a record from staging environment to live 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.
• Audit signature — who, when, what record, what state — recorded per publish and promote event.
• Prior-version retention — the platform's discipline of keeping the version each publish replaced.
• Recovery surface — operator-tier entry point for restoring prior versions of a record.
• Working version — the in-progress draft an operator is editing.
• Published version — the version visible at the public URL of the record's environment.
• Bulk operation — a dedicated surface that runs publish / archive / promote across many records at once.
• Visibility transition — a state change that moves a record into or out of the published state in its environment; publish, promote, unpublish, and archive each cause a visibility transition.
• Audit trail — the platform-managed record of every visibility-affecting operation; queryable through the per-site administrative surface.
• Trigger — the platform-side mechanism that fires a scheduled publish at the scheduled moment; recorded under platform identity in the audit signature with the originating operator preserved.
• Unpublish — the operation that reverses publish, returning a record to draft state in its current environment; preserves prior published version for recovery.
• Operator-tier — the surface and abstraction level that operators interact with; the publishing model is exposed at this tier rather than at the database tier.
• Database tier — the underlying storage SGEN runs on; operators do not interact with this tier directly. The recovery surface intentionally exists at the operator tier so prior-version restoration does not require database engineering.
• Per-record granularity — the default scope of save, publish, and promote; each operation acts on one record at a time unless an explicit bulk surface is invoked.
• Bulk surface — a dedicated administrative entry point that runs save / publish / promote / archive across many records as a single audited event.
• Originating operator — the operator who scheduled a deferred publish; preserved in the audit signature even when the platform identity is the actor that fires the trigger.