Version history

Version history organizes confirmed collaborative changes into browsable versions. Developers and users can inspect authors, timestamps, and actions, open historical content, review changes, and restore a version when permitted. History remains available across editing sessions and page reloads.

How version history works

• Mutation: A replayable content change, such as setting a cell or inserting a paragraph.
• Changeset: A collaboration submission containing an ordered group of mutations.

1. Record changes

When edits are submitted. User or Agent edits produce mutations, which are packaged into a changeset and submitted for collaboration confirmation and persistence.

A revision identifies a confirmed submission’s position in document history. History indexes confirmed changesets and groups them by time and operation to build the version timeline.

2. Reconstruct historical content

When a historical version is selected. A snapshot is the complete content state at a revision. The system loads a baseline snapshot and the subsequent changesets up to the target revision, then replays their mutations in order to produce a read-only historical view.

For example: snapshot at revision 10 + changesets for revisions 11–15 = content at revision 15.

3. Restore the current document

When Restore this version is selected.

Select a target version → Submit a restore mutation → Collaboration confirms → Update the current document at a new revision

The restore operation creates a new history record, while earlier versions remain available.

Browse versions and changes

1. Open Version history from the editor and select a version.
2. Expand a version group to inspect individual revisions. Select an entry to review its content and changes in a read-only viewer.
3. Select Restore this version when a rollback is needed. Restoration updates the current shared document through collaboration, so other participants receive the change.

A version group can combine edits within a time window. Expand it to inspect individual revisions. A history entry is not necessarily one keystroke or one generated Snapshot.

Read the change colors

Colors indicate change types. A text replacement may show both an insertion and a deletion. Each product viewer determines the highlighted scope.

History across five products

The following Northstar project examples use English content and expanded timelines to show content alongside the underlying actions.

Sheets

Review budget and forecast adjustments in Launch Budget, together with row insertions and deletions. The worksheet and action timeline help locate the area affected by each change.

Integrate Sheets history

Docs

Inspect the launch date, paragraph formatting, and customer-readiness additions in Product Launch Brief. Deleted text remains visible with red strikethrough, keeping revisions in context.

Integrate Docs history

Slides

Trace target metrics and page objects in Launch Review. Select a history entry to see updated, inserted, and removed objects directly on the slide.

Integrate Slides history

Relational Table

Review task, owner, and status changes in Launch Tracker. Record and field changes appear in the table context, helping explain when and how business data changed.

Integrate Relational Table history

Canvases

Revisit planning cards and object properties in Release Workspace. Inserted, deleted, and updated objects remain marked in their spatial context, making a planning revision easier to follow.

Integrate Canvases history

PDF

Coming soon: PDF version history is not yet available.

Integrate with your application

Version history combines the Server SDK History extension with Web SDK product history plugins:

• Server: add History Service, Endpoint, and a persistent Database Adapter to Core Collaboration. The service subscribes to Unit creation and committed changesets, builds a history index, and exposes version and changeset queries.
• Browser: register the common history capability and the product's History / History UI plugins, then connect the history endpoint. The viewer loads the selected revision and displays its changes. Register the appropriate viewer plugins for custom content.
• Permissions: your application supplies identity and authorization; the server checks history-read and restore permissions. Historical versions can contain data already removed from the current document.

See collaboration extensions, assemble the service with the History example, then connect the UI using the product guides above.

History indexes are rebuildable derived data. Confirmed changesets remain the authoritative content source. Your application controls persistence and retention; the history panel does not replace backups.

History, undo, comparison, and Worktree

Agent changes made through Facade APIs can enter the same history pipeline once collaboration confirms them. Applications can combine history with content comparison for automated review and checks.

Back to all features