Publishing Lifecycle: Draft, Publish, Update Content with State Clarity
How content moves through draft, publish, and update inside SGEN — consistent across every authoring surface.
The Publishing Lifecycle is the rule that every piece of content in SGEN follows: it starts as a draft, becomes published when an operator decides it should be public, and gets updated through the same governed save path whenever it changes again.
The lifecycle is the same whether you author a page in the admin, edit it visually in SG-Builder, write a blog post, or manage any other content object. The authoring surface changes. The lifecycle does not.
This page is the operator's reference for that lifecycle: what state a piece of content is in at any moment, how to move it forward, and how to recover when a publish or update fails.
Read it end-to-end the first time you author content in SGEN. The lifecycle is short and consistent, and knowing the recovery shape before you encounter a failure is the difference between a calm recovery and a confused one. After the first read, the lifecycle becomes second nature — most content work touches only the routine draft-publish-update path, with the recovery surfaces available when something needs them.
What is this for?
The Publishing Lifecycle governs the state of every content object in SGEN. It applies to pages, blog posts, templates, and any other content the platform manages through the same authoring path.
Reach for this reference when you need to understand whether a piece of content is in draft, published, or being updated, how to move it from one state to the next without ambiguity, how scheduling and revision behavior fit inside the same lifecycle rather than around it, and how content state relates to environment state (Stage and Live).
The lifecycle is also the reference to reach for when an action does not behave as expected. A publish that did not appear to take, an update that seems to have reverted, a scheduled action that did not fire — each one resolves into a clear answer through the revision history, because the revision history is the authoritative record of what actions the lifecycle executed.
The lifecycle is content-scoped. Environment promotion is a separate, larger movement covered in Stage and Live.
Why a single lifecycle across surfaces
The lifecycle is the same whether you author through the admin or SG-Builder. That consistency is deliberate. Authors who move between surfaces — a copy writer who drops into SG-Builder occasionally, a designer who edits copy through the admin — find the same draft, publish, update behavior in each surface, with the same state markers and the same revision history. Surface choice becomes about authoring style rather than about lifecycle behavior. The result: content state is predictable, surface-switching does not produce surprising state changes, and the team can collaborate across surfaces without lifecycle confusion.
Good use cases
- Authoring a new page, holding it as a draft, and publishing it when the page is ready.
- Updating a published page with new content and saving the update through the same governed path.
- Scheduling a published change for a future moment without breaking lifecycle clarity.
- Reading a revision history to understand who saved what, when, and from which surface.
- Resolving the question "is this page live?" with one clear answer from the content surface.
- Co-editing a content object across the admin and SG-Builder with no risk of one surface overwriting the other silently.
- Recovering from a publish failure with the draft preserved and a clear path to retry.
- Reading the full life of a content object end-to-end through the revision history.
What the lifecycle does not try to do
The lifecycle is intentionally narrow. It governs state — draft, published, updated — and nothing else. It does not try to be a workflow engine with multi-stage approvals, a content-modeling tool with field-level versioning, or a collaboration tool with real-time co-editing. Those concerns belong to other surfaces or other layers. The lifecycle keeps its scope tight so the answer to "what is the state of this object?" stays one clear value, every time, on every surface.
What NOT to use this for
- Moving a whole prepared site version from staging to production — that is the Stage and Live surface.
- Reversing a release across an entire environment — that is also Stage and Live.
- Theme or template-engine changes that are not content objects — those flow through their own authoring path.
- Permission changes that govern who can publish — those are user and role settings, not lifecycle state.
- Bulk import or export of content — bulk operations live on their own tooling and respect the lifecycle, but the lifecycle itself is a per-object surface.
- Site-wide configuration changes that are not tied to a content object — those flow through site settings.
- Media library management — media respects its own asset lifecycle, separate from content state.
How this connects to other features
- Stage and Live — environment-class movement that sits above content-class lifecycle. Publishing a page makes that page live in the current environment. Stage and Live moves the whole environment forward.
- Deployment & Release Overview — the broader release model. Content publishing is the day-to-day operation inside the model.
- Environment Model — staging versus production as concept. Publishing happens within the active environment.
- SG-Admin Overview — the content-administration surface where most lifecycle actions originate.
- SG-Builder — the visual authoring runtime where the same content objects can be edited without changing the lifecycle that governs them.
How the lifecycle relates to each surface in turn
The lifecycle is the connecting thread across every authoring surface in SGEN. SG-Admin treats it as the explicit save model on every content listing. SG-Builder treats it as the editor-toolbar action set, integrated into the visual editing experience. Stage and Live treats it as the building block under environment movement — every content object inside a promoted environment carries its own lifecycle history forward. The Deployment & Release Overview treats it as the day-to-day operation that fills the gaps between major releases.
Each surface reads the lifecycle from a different angle, but the state model is the same one. Read that consistency as the platform-wide guarantee that content state is never ambiguous, regardless of where the content was authored or where it is being consumed.
Before you start
The lifecycle assumes a few preconditions are already true.
You need an authenticated SGEN session and the role permissions needed to author the content type you are working with. You need the correct site scope selected so the content you save belongs to the right site. You need a valid content object — either an existing one you are updating, or create permission for a new one. For visual authoring, the relevant builder runtime must be reachable from the content object.
If any precondition is missing, the lifecycle surface will block the action rather than save silently.
Knowing the content type you are working with
The lifecycle is the same shape across content types, but the surrounding context — required fields, available templates, scheduling support — varies. A page has different required fields than a blog post. A blog post has different required fields than a template. Before triggering publish for the first time on a new content type, read the field-level requirements for that type so the first publish does not bounce on a validation failure that could have been caught while drafting.
For ongoing work on a content type you already know, the field requirements are second nature. The lifecycle then becomes the one consistent surface across types, while the content shape varies.
Where to find it
Lifecycle controls appear wherever you author content. Inside SG-Admin, every content listing (pages, blog posts, and so on) shows the current state of each entry. Inside SG-Builder, the same controls are integrated into the editor toolbar.
The placement varies by surface but the behavior does not. SG-Admin presents the controls as a save panel on the entry editor. SG-Builder presents them as toolbar buttons near the editor's top edge. Both surfaces trigger the same underlying lifecycle transitions, attribute the action to the operator account in the same way, and record the action in the same revision history. Operators who switch between the two surfaces see one consistent state model even as the visual presentation differs.
The three lifecycle controls are consistent across surfaces:
- Save as draft — keeps the content in working state, not visible on the public site.
- Publish — moves the content into the in-force state, visible on the public site within the active environment.
- Update — used after a published content object receives further edits, re-saved through the same governed path.
Reading the state marker on a listing
The state marker on a content listing is the fast read for current state. A draft marker means the entry has never been published, or has been reverted to draft. A published marker means the entry is current on the public site. An updated marker means the entry is published and has received an edit more recent than the original publish. A scheduled marker means a scheduled transition is queued. A failure marker means a recent action did not complete and the entry holds the prior state.
The markers are designed to be readable at a glance across a long listing, so a content owner scanning a list of fifty entries can see at a glance which ones are draft, which are live, and which are queued for a scheduled change. The detail view of each entry shows the full revision history if the listing read is not enough.
Scheduled actions sit inside the same lifecycle
Scheduling is not a separate state. A scheduled publish is a deferred publish action; a scheduled update is a deferred update action. The schedule marker reads as a pending action with a time attached. When the scheduled moment arrives, the lifecycle moves the object through the standard transition and the marker updates to reflect the new state, with a note in the revision history that the transition was triggered by the schedule rather than by a direct action.
Treat scheduling as a convenience layer on top of the lifecycle, not as a parallel mechanism. The same state-clarity guarantees apply.
Steps
The most common path is the full lifecycle of a single content object: create, draft, publish, update later, and read state at any point. The procedure below walks that path once.
How the lifecycle compresses across short editing sessions
For a short editing session — a quick correction to a published page, a small copy tweak, a single field update — the lifecycle compresses to two visible steps: open the object, save the update. The underlying state model is the same as the full lifecycle, but the operator does not need to walk every step on every edit. The compression is by design — the lifecycle is shaped to be heavyweight only at the moments that matter (the first publish, a recovery from a failure, a scheduled action) and lightweight for routine work.
Routine updates that pass through the lifecycle quietly are the common case. The heavyweight steps are the exceptions, and the surface is built to make those exceptions visible when they happen.
1. Create the content object and save as draft
Open the relevant content listing in the admin (pages, blog posts, or another supported type). Create a new entry. Add the content you have so far.
Save as draft. The entry now exists in the content store with a clear draft state. It is not visible on the public site. The listing shows the draft marker beside the entry.
Drafts are the baseline. Every content object starts here.
Drafts can be saved as many times as the author needs. Each save updates the working state without changing the published state. For a long-running draft worked on over days or weeks, this is the normal pattern — repeated draft saves, then a single publish action at the end. The revision history records each draft save so the work-in-progress trail is preserved.2. Publish when the content is ready
Reopen the draft when the content is ready for the public site. Review the content one final time on the authoring surface.
Trigger publish. The lifecycle records the state change — the content moves from draft to published. The platform marks the publication time and the operator account that triggered it. The content becomes visible on the public site within the active environment.
Publish is a state transition, not a button label. The lifecycle records the move explicitly.
Publish is also the moment validation runs in earnest. Field validations that did not block a draft save will block publish if they are not satisfied. Required fields must be present, formatted slugs must be unique, any field-level constraints must be met. Reading the validation messages — if any — and resolving them before retrying publish is the fast path to a clean transition.3. Update later through the same path
When the published content needs to change, open it again on the authoring surface. Edit what needs to change.
Save the update through the same governed path. The lifecycle records that this is an update to an already-published object, attributes the change to your operator account, and updates the public version under the same content identity.
The published state stays in force. The content under it changes. The lifecycle keeps both true at the same time.
An update is the right path for any change to an already-published object that you want to take effect immediately on the public site. If the change needs review before going public, save the changes to a draft revision and publish later — though that pattern is less common for incremental updates to live content. Most teams treat updates as the routine path for live-content edits and reserve draft-then-publish for new content.4. Use scheduling within the lifecycle, not around it
If the platform exposes a scheduled-publish or scheduled-update option for the content type, the lifecycle rule still applies. The scheduled action moves the object from draft to published (or saves an update) at the scheduled moment — it does not invent a new state.
Read the schedule as a deferred trigger of the same lifecycle, not as a bypass of it.
5. Read state at any moment
At any time, the content listing shows the current state of every entry: draft, published, or recently updated. The revision history shows the sequence of state changes with operator and time.
State is never hidden. The lifecycle is built so the answer to "what is the state of this content right now?" is always one clear value.
6. Use the revision history for past-state questions
The listing shows current state. The revision history shows past state. For a question about what happened before — when did this last change, who last published this, did the scheduled update fire — the revision history is the surface to open. Each entry shows the action, the operator, the time, and the resulting state. Reading the history end-to-end shows the full life of the object from first draft to current state, with every change attributed.
The history is also the recovery surface when a save appears to have gone wrong. If the listing and the visible content disagree, the history is the authoritative record of what happened. Trust it over a held editor session or a cached listing view.
What success looks like
A correctly-functioning lifecycle has four signals:
- The authoring surface shows an explicit save, publish, or update confirmation after every action.
- The content listing reflects the new state within the same view, without a forced refresh.
- The revision history records the state change with operator account and time.
- The public site reflects the change within the active environment when reopened.
| State at this moment | What the listing shows | What the public site shows |
|---|---|---|
| Draft saved, never published | Draft marker | Nothing — content not yet public |
| Published successfully | Published marker, publication time | Current published version |
| Update saved on a published object | Published marker, updated time | Updated version |
| Scheduled publish pending | Scheduled marker with time | Prior public state (if any) until scheduled moment |
| Publish failed | Failure marker, prior state preserved | Prior published version (or nothing if never published) |
| Update failed on a published object | Published marker held, failure noted on the entry | Prior published version still in force |
| Scheduled trigger executed | Published or updated marker with scheduled-trigger note | New version visible from the scheduled moment forward |
| Save in progress | Working marker, action disabled | No change until save resolves |
| Draft reverted from a failed publish | Draft marker reinstated | Nothing (or prior version if previously published) |
Reading state across multiple authoring surfaces
When the same content object is opened in both the admin and SG-Builder by different operators, both surfaces read the same underlying state. A publish triggered from SG-Builder shows in the admin listing on the next refresh. An update saved from the admin shows in the SG-Builder editor when the editor reloads the object. The lifecycle is the single source of truth — the surfaces are windows onto it, not separate state stores. If two surfaces disagree, the listing in the admin is the surface to trust, because it reads directly from the content store rather than from a held editor session.
What to do if it does not work
Lifecycle actions can fail. The lifecycle is designed so that a failed action does not leave the content in an ambiguous state — the prior state is preserved.
| Failure mode | What it means | What to do |
|---|---|---|
| Permission denied on publish | Your role cannot publish this content type | Save as draft and ask an operator with publish rights to complete the publication |
| Validation failure on save | A required field is empty or in an invalid state | Read the field-specific message, correct the field, save again |
| Slug or permalink collision | Another content object already uses this slug | Edit the slug to make it unique, then re-save |
| Save failure mid-action | The save service hit an error before completing | Do not retry blindly — refresh the surface, confirm current state, then retry |
| Builder save returns no confirmation | The builder runtime did not confirm the save | Re-open the content object, confirm the visible state, save again only if the change is missing |
| Scheduled publish did not fire at the scheduled time | The scheduler hit an error at the scheduled moment | Open the revision history, confirm whether the scheduled event recorded, publish manually if the schedule failed to execute |
| Published object missing from the public site | Caching or environment scope mismatch | Confirm the object is published on the active environment, then check for a cache layer between the content store and the public site |
| Two operators saving the same object | A second save arrived while the first was in flight | The lifecycle holds the last completed save — coordinate with the other operator and confirm what state the listing shows |
| Update reverted to prior content unexpectedly | A scheduled trigger executed older content | Open the revision history, identify which trigger executed, correct the scheduled content and re-save |
| Builder shows stale content after a publish | The editor session held an older copy in memory | Close and reopen the object in the builder — the editor reloads from the lifecycle state |
| Listing state does not match revision history | Cached listing view is behind the underlying state | Refresh the listing, the cached view should update to match the revision history |
Recovering a draft from a failed publish attempt
When a publish attempt fails, the lifecycle preserves the draft rather than leaving the content in a half-published state. Reopen the object — the draft content is intact, the failure marker is visible, and the lifecycle is ready for a second publish attempt once the underlying issue is resolved. Read the failure message before retrying. If the message names a specific field or validation rule, fix that field first. If the message names a service-level error, refresh the surface and confirm whether anything was partially recorded before retrying.
Examples
Example 1: Drafting and publishing a new product launch page
A site operator drafts a new product launch page over three days. On day one, the operator creates the page with the hero section and saves as draft. On day two, the operator adds the feature sections and saves again — the draft state holds across both saves. On launch morning, the operator does a final review on the authoring surface and triggers publish. The lifecycle records the publish event, the page becomes public within the active environment, and the launch goes live with a clear state record of who published when.
Example 2: Updating a published blog post with a correction
A published blog post has a factual error in one paragraph. A content editor opens the post in the admin, edits the paragraph, and saves through the update path. The lifecycle records the change as an update on an already-published object, the public site reflects the corrected paragraph, and the revision history shows both the original publish and the correction with the editor's account and time. The post never returns to draft state — the correction happens inside the published state.
Example 3: Scheduling a feature page change for a product release
A marketing operator needs a feature page to change wording at 09:00 on release day. The operator edits the page on the authoring surface, schedules the update for 09:00, and confirms the schedule on the listing. Before 09:00, the listing shows the scheduled marker. At 09:00, the lifecycle triggers the update through the same governed path — the change is recorded as a scheduled update, not as a new state. After 09:00, the listing shows the updated state with the scheduled trigger noted in the revision history.
Example 4: Co-editing a page across the admin and SG-Builder
A content writer drafts a page in the admin and saves the copy. A designer opens the same page in SG-Builder to apply layout and visual styling. The designer publishes the page when the layout is ready. The writer reopens the page in the admin to make a final copy correction, sees the published state on the listing, and saves an update through the admin path. The revision history shows the full sequence — draft from the writer, publish from the designer, update from the writer — with each entry attributed to the operator and surface that performed it. Two surfaces, one lifecycle, one clear history.
Example 5: Resolving a publish failure caused by a slug collision
A content editor drafts a new page and triggers publish. The lifecycle blocks the publish and shows a slug-collision failure marker, noting that another published page already uses the same slug. The draft is preserved — the editor reopens it, edits the slug to a distinct value, and triggers publish a second time. The lifecycle records the second attempt as a successful publish. The revision history shows the failed attempt with the collision reason, followed by the successful attempt with the corrected slug. The clear failure-then-recovery trail makes the resolution self-explanatory to anyone reading the history later.
Reading a revision history end-to-end
A content object's revision history is the audit trail for everything that has happened to it. Each entry shows the operator account that performed the action, the time the action completed, the surface the action originated from, and the resulting state. Reading the history end-to-end shows the full life of the object — from its first draft save through every publish, every update, every failed attempt, every scheduled trigger.
For an object with a long history, the revision history is also the answer to questions that would otherwise require interrupting the team. "When did this page change last?" "Who published this?" "Did the scheduled update fire?" — all answered by reading the history.
How the lifecycle interacts with environment promotion
The lifecycle governs content state within an environment. Stage and Live, covered separately, governs movement between environments. The two layers compose cleanly: content published inside a staged environment becomes live on the staged environment within the lifecycle, and then becomes live on the public environment when Stage and Live promotes the staged environment forward.
The key distinction: a publish action is content-scoped and acts within the active environment. A promotion action is environment-scoped and moves a whole prepared environment forward. Both honor the same state-clarity discipline — explicit transitions, recorded operator and time, prior state preserved if the action fails.
When in doubt about which layer is responsible for a given action, the rule of thumb is scope. If the change touches one content object, the publishing lifecycle governs it. If the change touches the whole environment, Stage and Live governs it.
Permissions and the lifecycle
The lifecycle respects role permissions on every action. A role with draft-save permission but no publish permission can create and update drafts but cannot trigger publish — the publish action is hidden or shows a permission-denied marker for that role. A role with publish permission can move objects from draft to published, but may or may not have permission to delete published objects depending on how the role is configured.
Permissions are a settings concern, not a lifecycle concern, but they show up in lifecycle actions. If a publish or update appears blocked unexpectedly, the first check is the role on the account being used, not the lifecycle state.
When the revision history is the source of truth
The listing view is the fast read for current state. The revision history is the authoritative read for full state. If the two ever appear to disagree — typically because of a cached listing view that has not yet refreshed — the revision history is the answer.
The revision history is also the surface to open when a question arises about an action that has already happened. Did the scheduled publish fire? Was the update saved by the operator who claims to have saved it? Did the failed attempt leave the prior state intact? Read the history — the answer is recorded there.
What to remember about the lifecycle in practice
Three takeaways carry most of the practical value of the lifecycle. State is always one clear value — draft, published, updated, scheduled, or held after a failure — and the listing view always shows that value at a glance. Transitions are explicit — every move from one state to another is an operator action, recorded with operator and time. Failures preserve prior state — a failed publish leaves the draft intact, a failed update leaves the prior published version in force, and the revision history is the authoritative record of what happened.
Carry those three takeaways into every authoring session and most lifecycle questions answer themselves.
Common confusions worth heading off
Two confusions show up regularly. The first is treating draft as a separate version of content rather than as an unpublished working state — drafts are working state, not parallel content. The second is treating an update as a republish — an update changes the content under an already-published object, the published state does not move, and the revision history records the update as an update, not as a second publish.
Both confusions resolve into the same answer: read the state marker, read the revision history, trust both.
A short summary worth carrying into every session
Draft is working state. Published is in-force state. Update changes the content under a published object without moving the state. Scheduled is a deferred trigger of the same lifecycle, not a parallel state. Failure preserves prior state and surfaces a failure marker. Revision history is the authoritative record. Both the admin and SG-Builder read and write through the same lifecycle.
That summary fits in one paragraph and covers most authoring sessions end-to-end.
Reading the lifecycle as the platform's quiet backbone
The lifecycle does not call attention to itself in day-to-day work. Most authoring sessions touch it without thinking about it — open the object, edit, save, close. The lifecycle's value is precisely that it stays quiet during routine work and shows up clearly only at the moments that matter: a state transition, a scheduled trigger, a failure recovery, a question about who did what when. Read it as the quiet backbone of every authoring surface in SGEN, present in every action but rarely the visible part of the interaction.