Record lifecycle

Record versioning

Record versioning is available only for records created from managed schemas.

A record may have multiple versions, and each version has its own state.

• Only the published version is used to generate content. Other versions can be retrieved through the API only when you request them explicitly.
• Exactly one version of a record is published at a time.
• Only one version of a record can be scheduled at a time. A record can have a published version and a scheduled version at the same time.
• A record holds one draft at a time.
• Only drafts can be edited. Draft versions operate in complete isolation from live content systems.
• Multiple unpublished versions can coexist for comprehensive historical tracking.
• Unpublished versions cannot be published again directly. You must edit the unpublished version as a new draft first, and then publish that draft.

Record states

The table below lists all possible states a record version can have. It also explains the conditions under which a version transitions into each specific state, based on the type of schema used to create the record.

State transitions

In the diagram, a solid line means that the same version changes its state. A dashed line means that a draft is created from the version, and the version keeps its state.

Editing as a new draft

Published and unpublished versions cannot be edited. To change their content, edit the version as a new draft. A draft is created from the version, and the version keeps its state:

• A published version keeps serving content until you publish the draft.
• An unpublished version stays unpublished. This is the only way to publish its content again.

A record can have only one draft. If the record already has a draft and you edit another version as a new draft, no new draft is created. Instead, the content of the existing draft is replaced with the content of the version you edit, and the draft keeps its version number. Any changes in the existing draft are lost.

Versions after a schema change

Each record version is saved with the version of the schema that was current at the time. After you change the fields of the schema:

• The published version keeps serving its content until you replace it. For details on how schema changes affect generated content, see Editing schemas.
• To change the content of a version saved with an earlier schema version, edit it as a new draft. The draft uses the current schema version and keeps the values of the original version.

Record scheduling

Brickworks provides organizations with precise control over content timing and availability through a powerful, built-in scheduling system that automates the entire content lifecycle.

Rather than depending on manual deployments or scrambling with last-minute updates, teams can strategically plan, prepare, and orchestrate content activation to seamlessly align with business objectives, marketing campaigns, seasonal events, or compliance deadlines.

This scheduling capability transforms content management from reactive to proactive, enabling teams to work ahead of deadlines while ensuring content appears exactly when needed, whether that's a product launch at midnight, a promotional campaign during peak hours, or regulatory content that must be active within specific timeframes.

Publishing options

When saving a record from draft state, users have flexible publishing options to control exactly when content goes live:

• Publish Immediately - The record transitions directly to published state and can be used to generate content instantly. The previously published version becomes unpublished. This option is ideal for urgent content updates, critical fixes, or when you need immediate content availability without delay.
• Schedule for Future Publication - Set a specific date and time for automatic publication. The record enters the scheduled state and will automatically transition to published at the designated moment. The previously published version becomes unpublished at the same moment. Perfect for coordinating product launches, marketing campaigns, or time-sensitive announcements across multiple channels.
• Time Window Publishing (Optional) - Define both a start date/time and an end date/time to create a limited-availability content window. The record will automatically transition from Scheduled → Published at the start time, then automatically move from Published → Unpublished when the window expires. This ensures content is only live during the specified period, making it ideal for limited-time offers, seasonal content, event-specific information, or compliance-sensitive materials that must be removed after a certain date.
• Automatic State Management - All scheduled transitions happen automatically without manual intervention, ensuring your content lifecycle operates precisely according to your business requirements and timing constraints.

An end date takes content down, it does not replace it. Use it when nothing should be live afterwards. To replace content at a specific time, schedule the new version instead. Publishing the new version replaces the live version, so you don't have to set an end date for the live version or unpublish it separately.

Only one version can be scheduled at a time. If you schedule another version while one is waiting, you are asked to confirm, and the waiting version becomes unpublished. Publishing a draft immediately does not cancel the waiting version: it still goes live at its start date.

Versioning and editorial workflow

Record scheduling integrates with Brickworks' versioning system to provide a smooth editorial experience that never disrupts live content. A published version cannot be edited. To modify it, edit it as a new draft:

• A new draft version is created from the published version, preserving your live content.
• The current published version remains active and is used to generate content until you decide to replace it.
• Upon completing your edits, you have full control over the transition:
  • Replace immediately - Publish the draft to override the live version instantly with your changes. The previous version becomes unpublished.
  • Schedule replacement - Set a future date/time for the new version to go live automatically. The previous version becomes unpublished when the new version goes live.
  • Continue refining - Keep working on the draft without affecting the published content.
• Every published version is preserved in a comprehensive log that captures the complete content history, including version, timestamps, user actions, and change details. More about versioning can be found in Record Versioning.

Real-life use cases for scheduling

• Retail Operations: Launch flash sales, seasonal promotions, or price changes at precise times (like midnight Black Friday deals) without requiring overnight staff or manual intervention.
• Marketing Campaigns: Schedule entire campaign content weeks in advance and automatically retire promotional materials when campaigns expire, ensuring consistent messaging across all touchpoints.
• Legal & Compliance: Deploy time-critical documents such as updated terms of service, privacy policies, or regulatory disclosures to become effective exactly when legally required.
• Product Development: Coordinate content releases with feature launches, app updates, or system deployments by preparing changes well in advance and scheduling them to align perfectly with technical rollouts.

Strategic business value

Record scheduling transforms content operations by delivering:

• Operational excellence – Eliminate manual publishing processes and reduce coordination overhead between teams, allowing content operations to run smoothly without constant supervision.
• Risk reduction – Prevent costly mistakes from premature content releases or missed deadlines for time-sensitive materials, ensuring content accuracy and compliance.
• Strategic coordination – Enable cross-departmental alignment and multi-channel content synchronization without requiring engineering resources or technical intervention for routine content operations.