# Previewing future states with timeline

### About this export

| Field | Value |
| --- | --- |
| **content_type** | lesson |
| **platform** | contentstack-academy |
| **source_url** | https://www.contentstack.com/academy/courses/preview-visual-builder-and-releases/previewing-future-states-with-timeline |
| **course_slug** | preview-visual-builder-and-releases |
| **lesson_slug** | previewing-future-states-with-timeline |
| **markdown_file_url** | /academy/md/courses/preview-visual-builder-and-releases/previewing-future-states-with-timeline.md |
| **generated_at** | 2026-08-03T11:49:51.825Z |

> Part of **[Preview, Visual Builder, and Releases](https://www.contentstack.com/academy/courses/preview-visual-builder-and-releases)** on Contentstack Academy. **Academy MD v3** — structured for retrieval; no quiz or assessment keys.

<!-- ai_metadata: {"lesson_id":"10","type":"text","duration_minutes":1,"topics":["Previewing","future","states","with","timeline"]} -->

#### Lesson text

# Previewing future states with timeline

> **TL;DR**
> 
> *   Standard Live Preview shows a single entry's draft; "time travel" preview composites all scheduled changes to show the full site state at a target date.
> *   Three implementation approaches exist: preview all drafts (simplest), date-parameterized preview (more targeted), or Release-scoped preview (most precise but most code).
> *   Overlapping Releases targeting the same entry on the same date have no automatic conflict resolution -- the last one to execute wins.
> *   Future-state preview requires a separate preview environment with no-cache policies and context-aware content resolution.

Scheduling content for the future is only half the problem. The other half is answering the question editors ask immediately after scheduling: "What will the site look like when this goes live?" If the answer is "you will find out when it publishes," you have a trust gap. Editors are scheduling content they cannot verify, which means they are either deploying blind or building elaborate workarounds like publishing to a hidden environment, taking screenshots, and then unpublishing. Neither approach scales.

Contentstack addresses this with capabilities that allow previewing future content states before their scheduled publish date. By combining Live Preview, entry timeline, the publish queue, and Release-aware preview, teams can validate exactly what visitors will see at a future point in time without prematurely pushing content to a live environment.

## The "time travel" concept

Traditional preview shows content in its current draft state. Time travel preview extends this by allowing you to see content as it will appear at a specific future date after scheduled publishes and Releases have executed.

Consider a retail brand preparing for the holiday season with this schedule distribution matrix:

Scheduled date

Content change

November 15

Publish "Holiday Collection" homepage hero

November 28

Release: Holiday Collection (12 entries)

December 1

Publish "Cyber Monday" promotional banner

December 15

Release: Digital Dawn Launch (8 entries)

December 26

Release: Post-holiday clearance (unpublish holiday content, publish clearance)

Without time travel preview, the editorial team has no way to verify what the homepage looks like on December 1 versus December 15 versus December 26. Each date represents a different combination of published and unpublished content, and the interactions between these scheduled actions may produce unexpected results. With time travel preview, an editor can select "December 15" and see the homepage with the Digital Dawn Launch content live, the Holiday Collection still active (or replaced, depending on the Release configuration), and campaign banners visible or expired. The preview renders the cumulative state at that point in time.

## Entry timeline: the publication history of a single entry

Every entry in Contentstack has a timeline that records its publication history: when it was published, to which environment, and when it was unpublished. This timeline is distinct from the version history (covered in the [versioning lesson](/course-4-preview-visual-builder-releases/module-4-2-scheduling-releases-versioning/02-versioning-comparison-rollback)). Version history tracks content changes (saves). The timeline tracks distribution events (publishes and unpublishes).

To view an entry's timeline:

1.  Open the entry in the entry editor.
2.  Look for the Timeline or Publish Details section.
3.  The timeline shows past publish events and any scheduled future publish actions.

The timeline answers infrastructure and history questions cleanly:

*   When was this entry last published to production?
*   Is there a scheduled publish pending for this entry?
*   Was this entry ever unpublished from staging, and when?

For the retail brand, the homepage hero entry's timeline might show the following parameters:

Date

Action

Environment

Version

Oct 1, 2025

Published

production

v5

Nov 15 (scheduled)

Publish

production

v8

This tells the editor that version 5 is currently live, and version 8 will automatically replace it on November 15.

## The publish queue: monitoring scheduled actions

The Publish Queue in Contentstack provides a centralized view of all pending, in-progress, and completed publish actions across the stack. This is where you monitor what is scheduled and when.

Navigate to Publish Queue in the left sidebar to see:

*   Pending items: scheduled publishes and Releases waiting to execute.
*   In Progress items: publish actions currently being processed.
*   Completed items: recently executed publish actions with their status (success or failure).

For the retail brand with five scheduled dates in November and December, the publish queue serves as the campaign calendar. The editorial director can open the queue and see every scheduled action, verify the timing, and identify potential conflicts (two Releases scheduled for the same minute, for instance).

The publish queue is also accessible via the Content Management API:

// check-scheduled-actions.ts  -  list all pending scheduled publishes
const response = await fetch(
  "https://api.contentstack.io/v3/publish-queue?status=scheduled",
  {
    headers: {
      api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
      authorization: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_MANAGEMENT\_TOKEN!,
    },
  }
);

const { queue } = await response.json();
queue.forEach((item: any) => {
  const name = item.entry?.title || item.asset?.title || item.release?.name;
  console.log(
    \`${name} → ${item.environment} | Scheduled: ${item.scheduled\_at}\`
  );
});

This programmatic access enables building a custom campaign dashboard that shows all scheduled content operations in one view, something the marketing team can reference without needing direct access to the Contentstack UI.

## Previewing scheduled content with Live Preview

Live Preview, covered in depth in the [preview requirements lesson](/course-4-preview-visual-builder-releases/module-4-1-live-preview-and-visual-builder/01-preview-requirements-and-concepts), renders draft content in the context of your frontend application. When combined with scheduled content, Live Preview becomes a future-state validation tool.

The core mechanism: entries that are staged for a scheduled publish exist in a saved (draft) state within Contentstack. Live Preview can render this draft state even though the entry has not yet been published. This means an editor can:

1.  Create or update an entry (e.g., the "Digital Dawn Launch" page).
2.  Add it to a Release scheduled for December 15.
3.  Open Live Preview to see how the entry renders in the frontend.

The preview shows the content as it will appear after publishing. The editor verifies layout, imagery, copy, and references before the scheduled date arrives.

> **Common pitfall:**
> 
> Standard Live Preview shows only the current entry's draft -- it does not composite all entries from a scheduled Release into a combined view. Approving a Release based on single-entry previews can miss cross-entry layout conflicts or broken references.

### Limitation: single-entry preview vs. full-state preview

Standard Live Preview shows the current entry in its draft state. It does not automatically composite all entries from a scheduled Release into a single preview view. If the Digital Dawn Launch Release contains eight entries (a page, three products, a navigation update, two hero components, and a product line), previewing any single entry shows that entry's draft content but not necessarily the combined effect of all eight changes on the full page. Achieving full-state preview requires additional implementation work, which we cover in the next section.

## Implementing Release-aware preview

To preview the complete future state of a page affected by a Release, your preview endpoint needs to serve content that reflects the Release's cumulative changes. This goes beyond standard Live Preview and involves architectural decisions in your frontend application.

### Approach 1: preview all draft content

The simplest approach is to configure your preview environment to always fetch draft content rather than published content. Since all entries in a scheduled Release have been saved (and are therefore in draft state), a preview endpoint that fetches draft content will naturally show the future state.

The examples choose specific destination endpoints (e.g., rest-preview.contentstack.com, cdn.contentstack.io). For EU/Azure/GCP stacks, use the matching regional hosts.

// preview-handler.ts  -  serve draft content for future-state preview
import contentstack from "@contentstack/delivery-sdk";
import { getContentstackEndpoints } from "@timbenniks/contentstack-endpoints";

const endpoints = getContentstackEndpoints(
  process.env.NEXT\_PUBLIC\_CONTENTSTACK\_REGION || "na",
  true
);

export function createPreviewStack() {
  return contentstack.stack({
    apiKey: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
    deliveryToken: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_PREVIEW\_TOKEN!,
    environment: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_ENVIRONMENT!,
    region: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_REGION,
    live\_preview: {
      enable: true,
      preview\_token: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_PREVIEW\_TOKEN!,
      host: endpoints.preview,
    },
  });
}

// In your page route handler:
export async function getPreviewPageData(slug: string) {
  const stack = createPreviewStack();
  const result = await stack
    .contentType("page")
    .entry()
    .query()
    .where("url", slug)
    .find();

  return result.entries\[0\];
}

This approach works well when your preview environment is isolated and dedicated to editorial validation. The trade-off is that it shows all draft content, not just the content in a specific Release. If multiple editors are working on different content simultaneously, the preview might show changes that are not part of the Release being validated.

### Approach 2: date-parameterized preview

A more targeted approach is to build a preview endpoint that accepts a date parameter and filters content based on what will be published by that date. This requires your frontend to resolve scheduled actions and serve the appropriate content version.

// future-state-preview.ts  -  preview site state at a specific future date
interface PreviewContext {
  targetDate: string; // ISO date string
  environment: string;
  locale: string;
}

export async function getFutureStateContent(
  contentTypeUid: string,
  entryUid: string,
  ctx: PreviewContext
) {
  // Step 1: Check whether a scheduled publish exists for this entry
  // before the target date
  const queueResponse = await fetch(
    \`https://api.contentstack.io/v3/publish-queue?content\_type\_uid=${contentTypeUid}&entry\_uid=${entryUid}&status=scheduled\`,
    {
      headers: {
        api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
        authorization: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_MANAGEMENT\_TOKEN!,
      },
    }
  );

  const { queue } = await queueResponse.json();
  const scheduledBeforeTarget = queue.filter(
    (item: any) => new Date(item.scheduled\_at) <= new Date(ctx.targetDate)
  );

  if (scheduledBeforeTarget.length > 0) {
    // A scheduled publish exists  -  fetch the draft version
    // that will be published
    const entryResponse = await fetch(
      \`https://rest-preview.contentstack.com/v3/content\_types/${contentTypeUid}/entries/${entryUid}\`,
      {
        headers: {
          api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
          preview\_token: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_PREVIEW\_TOKEN!,
        },
      }
    );
    return entryResponse.json();
  }

  // No scheduled change  -  return the currently published version
  const entryResponse = await fetch(
    \`https://cdn.contentstack.io/v3/content\_types/${contentTypeUid}/entries/${entryUid}\`,
    {
      headers: {
        api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
        access\_token: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_DELIVERY\_TOKEN!,
      },
    }
  );
  return entryResponse.json();
}

This approach resolves the correct content version based on the target date. For entries with scheduled changes before the target date, it serves the draft (future) version. For entries without pending changes, it serves the currently published version. The result is a composite view that reflects what the site will look like at the specified date.

### Approach 3: Release-scoped preview

The most precise approach is to build preview logic that is aware of specific Releases. Given a Release UID, the preview endpoint fetches all items in that Release and renders them together with the current published state of everything else.

// release-preview.ts  -  preview the combined effect of a specific Release
export async function getReleasePreviewData(releaseUid: string) {
  // Fetch all items in the Release
  const releaseResponse = await fetch(
    \`https://api.contentstack.io/v3/releases/${releaseUid}/items\`,
    {
      headers: {
        api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
        authorization: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_MANAGEMENT\_TOKEN!,
      },
    }
  );

  const { items } = await releaseResponse.json();

  // Build a map of entries that will change when this Release deploys
  const releaseEntries = new Map();
  items.forEach((item: any) => {
    releaseEntries.set(item.uid, {
      action: item.action,
      uid: item.uid,
    });
  });

  return releaseEntries;
}

// In your page rendering logic, use this map to decide
// whether to fetch draft or published content for each entry
export async function resolveEntryForPreview(
  entryUid: string,
  contentTypeUid: string,
  releaseEntries: Map
) {
  const releaseItem = releaseEntries.get(entryUid);

  if (releaseItem?.action === "unpublish") {
    // This entry will be removed  -  return null or placeholder
    return null;
  }

  if (releaseItem?.action === "publish") {
    // This entry is in the Release  -  fetch draft version
    const response = await fetch(
      \`https://rest-preview.contentstack.com/v3/content\_types/${contentTypeUid}/entries/${entryUid}\`,
      {
        headers: {
          api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
          preview\_token: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_PREVIEW\_TOKEN!,
        },
      }
    );
    return response.json();
  }

  // Not in the Release  -  fetch currently published version
  const response = await fetch(
    \`https://cdn.contentstack.io/v3/content\_types/${contentTypeUid}/entries/${entryUid}\`,
    {
      headers: {
        api\_key: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_API\_KEY!,
        access\_token: process.env.NEXT\_PUBLIC\_CONTENTSTACK\_DELIVERY\_TOKEN!,
      },
    }
  );
  return response.json();
}

This is the most accurate preview because it shows exactly what will change when a specific Release deploys, without being affected by unrelated draft content from other editors or future Releases.

## Combining Releases with Live Preview for campaign validation

The highest-value workflow combines Release management with Live Preview to give editors a complete campaign validation experience. Here is how this works for the retail brand's holiday campaign:

1.  **Assemble the Release:** the editorial team creates a Release named "Digital Dawn Launch - Dec 15" and adds all eight entries.
2.  **Preview individual entries:** each editor uses Live Preview to verify their individual entries render correctly (layout, images, copy).
3.  **Preview the composite page:** using a Release-aware preview endpoint, the editorial director previews the homepage as it will appear on December 15, with all eight entries composited together alongside unchanged published content.
4.  **Validate cross-entry interactions:** the director verifies that the new navigation item links to the new landing page, that the promotional banners do not overlap with existing banners, and that the hero image renders at the correct dimensions.
5.  **Approve and schedule:** after validation, the Release is scheduled with confidence that the future state has been verified.

This workflow collapses what would otherwise be a multi-day, multi-person coordination exercise into a structured preview-and-approve cycle.

## Handling multiple overlapping Releases

Real-world content operations rarely involve a single isolated Release. Veda has five scheduled dates in a six-week window, and some of these Releases affect the same pages. What happens when two Releases both modify the homepage hero?

This is where previewing becomes more nuanced:

*   Non-overlapping Releases: if Release A publishes a hero for November 28 and Release B publishes a different hero for December 15, the December 15 hero replaces the November 28 hero. Previewing each Release independently shows the correct state for each date.
*   Overlapping Releases: if two Releases scheduled for the same date both modify the homepage hero, the last one to execute wins. The publish queue processes items sequentially, and the final published version is the one that persists.

To prevent conflicts, the editorial team should review the publish queue for scheduling collisions. If two Releases target the same entry on the same date, the team must decide which takes precedence and adjust the other Release accordingly.

There is no automated conflict resolution for overlapping Releases. This is a content governance problem, not a technical one. The tools provide visibility (through the publish queue and Release item lists), but the decision about which content wins belongs to the editorial team. Consider establishing a Release review meeting for periods with heavy scheduling, like the holiday season, where the team walks through the publish queue and validates that no conflicts exist.

## Preview environment architecture considerations

Implementing future-state preview has explicit architectural implications for your frontend deployment configuration targets:

Concern

Production path

Preview path

Content source

Delivery API (published)

Preview API (draft) or mixed

Caching

Aggressive CDN caching

No cache or very short TTL

Authentication

Public (delivery token)

Restricted (preview token, IP allow)

URL routing

Standard routes

Standard routes + date/release params

Content resolution

Always published state

Published or draft, contextual

Your preview deployment should be a separate environment from production, with its own delivery/preview tokens and its own caching policy. Serving draft content through your production CDN is a security and correctness risk: unpublished content could leak to visitors, and cached draft responses could persist after publishing.

The preview environment should also support additional query parameters or headers for specifying the preview context (target date, Release UID, locale). These parameters drive the content resolution logic described in the implementation approaches above.

## Common mistakes

### Mistake 1: previewing individual entries and assuming the full page is correct

An editor previews a single entry from a Release and sees it renders correctly. They approve the Release. After deployment, they discover that another entry in the Release (a navigation change) conflicts with the previewed entry's layout. Always validate the composite page state, not just individual entries.

### Mistake 2: using the production environment for preview

Serving draft content through the production CDN to enable preview creates a content leak risk. Unpublished content may be served to real visitors, either through cache pollution or through unprotected preview URLs. Use a dedicated preview environment with access controls.

### Mistake 3: not accounting for overlapping scheduled actions

Two Releases are scheduled for the same date, and both modify the same entry. The team assumes both changes will apply, but only the last-published version persists. Review the publish queue for scheduling conflicts before approving Releases, especially during high-activity periods like product launches or seasonal campaigns.

## Summary

Previewing future content states bridges the gap between scheduling content and trusting that it will look correct when published. Entry timelines show the publication history and scheduled actions for individual entries. The publish queue provides a centralized view of all pending operations across the stack. Live Preview renders draft content for editorial validation, and Release-aware preview implementations can composite multiple future changes into a single, accurate view of the site at any target date. The architectural requirements for future-state preview include separate preview environments, context-aware content resolution, and cache policies that prioritize freshness over efficiency. When these elements are in place, editors can schedule with confidence rather than scheduling and hoping.

#### Key takeaways

- Connect **Previewing future states with timeline** back to your stack configuration before moving to the next module.
- Capture one concrete artifact (screenshot, Postman call, or code snippet) that proves the step works in your environment.
- Re-read the delivery versus management boundary for anything you changed in the entry model.

## Supplement for indexing

### Content summary

Previewing future states with timeline. Previewing future states with timeline TL;DR Standard Live Preview shows a single entry's draft; "time travel" preview composites all scheduled changes to show the full site state at a target date. Three implementation approaches exist: preview all drafts (simplest), date-parameterized preview (more targeted), or Release-scoped preview (most precise but most code). Overlapping Releases targeting the same entry on the same date have no automatic conflict resolution -- the last one to execute wins. Future-state preview requires a separate preview environment with no-cache policies and context-aware content resolution. Scheduling content for the future is only half the problem. The other half i

### Retrieval tags

- Previewing
- future
- states
- with
- timeline
- preview-visual-builder-and-releases
- lesson 10
- Previewing future states with timeline
- preview-visual-builder-and-releases lesson

### Indexing notes

Index this lesson as a primary chunk tagged with lesson_id "10" and topics: [Previewing, future, states, with, timeline].
Parent course slug: preview-visual-builder-and-releases. Use asset_references URLs as thumbnail hints in search results when present.
Never surface LMS quiz content or assessment answers from this file.

### Asset references

_No image or video thumbnail URLs were extracted._

### External links

| Label | URL |
| --- | --- |
| Contentstack Academy home | `https://www.contentstack.com/academy/` |
| Training instance setup | `https://www.contentstack.com/academy/training-instance` |
| Academy playground (GitHub) | `https://github.com/contentstack/contentstack-academy-playground` |
| Contentstack documentation | `https://www.contentstack.com/docs/` |