Publishing Model

In short. SGEN's publishing model has three operations: Save (persists your draft — nothing goes live), Publish (makes the record visible at its environment's URL — staging or live), and Promote (moves a record from staging to live — the only operation that crosses environments). Every publish and promote is audited: who, when, what state. The platform retains prior versions automatically, so recovery does not require rebuilding from memory. Save and publish are always separate — there is no "save to public" shortcut.

On this page: The three operations · A typical lifecycle · Audit and retention · Constraints · Examples · Vocabulary

Related pages: Environments and Site States · Roles and Access · SG-Admin Overview · Backups

The three operations

The publishing model covers every record type — Pages, Posts, Products, Forms, Custom Objects, Locations, Events — with the same three operations.

Save

Save persists the working version of a record. The working version is the in-progress draft an operator is editing — not yet ready for public visibility. Save is the lowest-stakes operation: save freely as you work.

Save does not change public visibility. A saved draft stays in draft state. The platform does not silently cross environments on save — saving on staging updates the staging working version only.

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, your customer-facing domain if publishing on live.

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.

Publish is reversible. Prior published versions are retained, so you can return to an earlier version through a recovery operation rather than rebuilding from memory.

Promote

Promote moves a record across environments — from staging to live. It is the only operation in the model that crosses an environment boundary, and structurally the heaviest because it changes what end users see at your customer-facing domain.

Promote takes the staging version and writes it as the live version. The previous live version is preserved and remains accessible through the recovery surface.

Promote is governed. The platform records who promoted, when, and what both the prior and new live versions looked like. The audit signature on a promote event is the strongest of the three because it changes end-user visibility.

A typical lifecycle

Audit and retention discipline

Every save, publish, and promote goes through a platform-managed audit and retention layer. Operators do not configure this per record — it is part of the platform's operating posture, on by default for every record across every module.

Audit signature

For each publish and promote, the platform records who ran the operation, when, what record, and what the record state was at that moment. The audit trail is queryable from SG-Admin — "what published last Tuesday on this Page?" or "who promoted this Product to live?" — no external log aggregation needed.

Prior-version retention

Each publish or promote retains the version it replaced. You do not have to copy a record before publishing in order to roll back; the platform handles retention as part of the publish event.

Backup coverage

Backups capture the entire record store including all states (draft, published, scheduled, archived) and the attached audit trail. Recovery from a backup restores the record store including audit context current at the moment of capture.

Recovery surface

The recovery surface is reachable from SG-Admin. Restoring a prior version is an operator-tier action — no database-level engineering required.

Constraints and boundaries

• Save and publish are separate operations. SGEN does not collapse them into a single button. Save persists working state; publish transitions visibility.
• Publish is per-environment. Publishing on staging makes the record visible at the staging URL only. There is no "publish to both" shortcut — that is what promote is for.
• Promote is the only operation that crosses environments. Treat it 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 the record entirely. Recovery treats them differently.
• Per-record granularity is the default. Bulk operations (publish many, promote a section, archive a campaign) are dedicated bulk surfaces, not side-effects of per-record operations.

Examples

A first publish that lands at the live URL

A content author creates a Page, saves several times while refining copy. The Page is draft on staging. They click Publish — the Page is now published on staging, visible at the staging URL but not the live URL. The team lead reviews, runs Promote. The Page is published on live — end users see it at the customer-facing domain. The audit trail records every save, publish, and promote with operator identity and timestamps.

A change that needs to be reverted after going live

A Post was promoted to live with a wrong image. The operator opens the Recovery surface, selects the prior published version, and restores it as the live version. Prior-version retention made the rollback possible without database-level work. The audit trail records the rollback next to the original promote event.

Why a save did not become visible

An operator saved an updated Page but the live URL still shows the old version. They forgot to publish after saving. They click Publish on staging, review, then Promote to live. The save events are in the audit trail, distinct from the publish event that finally changed visibility.

A scheduled publish that auto-fires

A marketing operator finishes a Post, schedules it on staging for 09:00 Monday, and promotes the scheduled record to live. At 09:00 Monday the platform fires the transition automatically. The audit trail records the auto-transition exactly as it would record a manual publish.

Bulk promote at the end of an editorial sprint

An editorial team finishes a sprint with twelve Posts ready on staging. The operator selects all twelve and runs the bulk Promote. 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 operator identity.

Related reading

• Environments and Site States — the where-and-state coordinates the operations move records between.
• Roles and Access — who can save, publish, and 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.

Vocabulary cross-reference

• Save — persist the working version; no public visibility change.
• Publish — transition a record to published state in its current environment.
• Promote — move a record from staging to live; the only operation that crosses environments.
• Schedule — set a record to publish at a future moment in its current environment.
• Archive — remove from public visibility while keeping the record 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.
• 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 published state; publish, promote, unpublish, and archive each cause one.
• Audit trail — the platform-managed record of every visibility-affecting operation; queryable from SG-Admin.
• Trigger — the platform-side mechanism that fires a scheduled publish; recorded under platform identity with the originating operator preserved.
• Unpublish — reverses publish, returning a record to draft state; preserves prior published version for recovery.
• Operator-tier — the surface level operators interact with; publishing is exposed here, not at the database tier.
• Per-record granularity — the default scope of save, publish, and promote; one record at a time unless a bulk surface is invoked.
• Originating operator — the operator who scheduled a deferred publish; preserved in the audit signature even when the platform fires the trigger.