Inspect changes and restore saved state

Unity records supported workspace changes so you can inspect what happened and restore earlier state where supported. Native edits and HTML authoring both participate in report editing history.

History is scoped recovery for saved operations. It is not an unlimited backup of every action, source-data change, or account setting.

Undo or redo an edit

Open the report and identify the recent change.
Use Undo or Redo when available.
Review the restored objects and data definitions.
For a complex assistant request, inspect its activity before deciding which operation to restore.

Ctrl/Cmd+Z invokes available workspace undo. Ctrl/Cmd+Shift+Z or Ctrl/Cmd+Y invokes redo when focus is not handling a separate text-edit action.

Stopping an active run does not undo its previous saves.

Inspect changes through the assistant

The assistant can use InspectChanges to inspect recorded mutations and UndoChange for supported restoration.

Inspect the changes from the last request. Identify the operation that
changed the monthly trend's SQL and explain its scope. Restore that
operation if it still matches the expected current state.

A mutation receipt can include object identity, operation, persisted status, and before/after state. Read these together with the current report.

Restore an HTML page version

Open the HTML page.
Click Page history.
Select a saved version.
Choose Restore version or Restore v….
Review the restored page and refresh or preview it as needed.

Restored by HTML page history	Kept at the current state
Page HTML and layout source	Current page name
Registered visual source and bindings	Current report/page filters
Registered dataset queries	Current access settings

The restore is itself a new operation that can be undone. Restoring a page version does not mean rewinding the whole report or changing its ownership.

Respect intervening changes

Restoration can compare the current state with the state expected after the original operation. If another edit has happened, Unity can report a conflict instead of overwriting it.

For example, an assistant might change a chart's title before a colleague changes its SQL. Reversing the older operation must account for that newer work.

After a conflict, inspect the latest definition and make a narrow correction or choose the intended restore target. Do not treat an old snapshot as automatically authoritative.

Understand the scope

Change	Scope to inspect
Visual appearance	The target visual's properties and current revision.
Visual query or bindings	Calculation, connection, returned fields, and filters.
Native page edit	Page settings and any included visual state.
HTML page version	Source, registrations, and dataset queries.
Page deletion or duplication	Contents and related identities, not just the page name.
Model definition change	Shared definition and dependent consumers; do not assume a page restore reverses it.

Invisible-page policy is retained independently of ordinary content restoration. Undoing or duplicating content must not make an invisible page available to viewers accidentally.

Recover a partial build

A multi-step assistant request is not one all-or-nothing transaction. It may save a page and two visuals before a third fails.

Read the activity, inspect the page, and choose whether to continue, correct one component, or undo recorded operations. Reversing one operation does not automatically reverse the entire conversation.

Inspect the partially completed page. Keep the working visuals and undo
only the failed layout replacement if restoration is still valid.
Then explain the remaining work.

History and access

History and snapshots can contain older report content. When invisible pages exist in the relevant history, these surfaces can require editing access even if current visible pages remain available to viewers.

History is not a way to bypass a page's visibility or a report's access policy. See Page visibility and Report ownership for those separate controls.