Undo

Global Undo reverses one latest supported successful transaction for the current user, when the server returned a valid Undo receipt. It is not a complete history, backup, or universal reversal of every edit.

Manual actions and AI actions can use the same command executor and receipt mechanism. An AI plan's description or "reversible" classification is not sufficient: a valid returned receipt is what makes global Undo available.

The fictional Product Atlas examples below use Aster Mini and Aster Pro under Lumen devices and a saved Table named Product prices by market. Orbit Dock and Orbit Hub remain unchanged. The rename exercises are temporary changes to the training fixture, not its initial labels.

Find The Undo Entry

Look for the Undo arrow in the global header. With no stored receipt, it is disabled and says Nothing to undo. When an entry exists, hover or focus it to inspect:

• The completed action summary.
• The time of that action.
• The changes included in the transaction preview.
• Any validation conflict, error, or browser-storage warning.

The preview describes the transaction being reversed; it is not a list of older actions you can choose from. A later supported transaction replaces the previous entry. Undo does not become a stack after you use it.

Undo A Supported Change

1. As an authorized Product Atlas Editor, rename Aster Mini to Aster Mini 2 using Details and complete Save.
2. Wait for the authoritative updated label and inspect the Undo entry.
3. Confirm that its summary refers to that rename, not an earlier change.
4. Click the Undo arrow once.
5. Wait for validation and execution, then inspect the reconciled resource label.

Expected result: if the rename returned a valid receipt and no conflicting edit occurred, the inverse restores the captured label. After success, the entry is cleared. There is no second confirmation dialog and no Redo.

If the same saved transaction changed a label and icon together, Undo reverses its supported inverse plan together. It does not let you choose just the label from that transaction.

What Can Return A Receipt?

Receipt support depends on command kind, creation versus update, captured prior state, returned revisions, and deployment configuration. These are current examples of supported inverse-plan paths, not promises that every matching UI workflow is reversible:

Snapshot adjustment command support does not imply period-drag controls exist in the current snapshot UI. See Snapshots for the actual authoring controls.

New standalone snapshot/value/property creation does not automatically have an inverse merely because updating an existing row does. A bundled creation beneath a new resource can have different support from creating the same field independently on an existing resource.

Always check the actual returned Undo entry after completion. A supported action in one release or workflow is not a blanket guarantee for all commands in that family.

Unsupported Or Irreversible Operations

The current inverse builder does not provide general reversal for deletions, standalone subject/property-family/property creation, Class/Alias conversion, snapshot-mode switches, linked-membership operations, resource-grid cell commands, condition/value reordering, or every specialized write path.

Project snapshot delete-and-merge is not covered. Snapshot saves using Activate and trim or split or Activate and move conflicts to inactive deliberately return no inverse plan: they can change or create additional periods, and a partial reversal would be unsafe.

The current Onepager Preview reference-drop workflow returns no receipt and clears the global Undo entry on success. Do not confuse a supported executor command with receipt coverage for every UI route performing a similar change.

Storage/file work, roles, invitations, ownership, account changes, and AI conversation/memory management are not universal Undo operations. Deleting an AI thread does not undo its data writes, and Undo does not restore the deleted thread.

If any required command in a transaction has no complete supported inverse, the transaction does not offer a partial Undo of the remaining commands. A successful receipt-less operation through the shared executor clears the current global entry. Successful irreversible workflows also clear it where integrated. Do not use an older preview as an assurance that an unrelated unsupported operation can be reversed.

Conflicts Protect Later Changes

Before execution, Undo checks the signed receipt, current user, expiry, accessible records, and expected record revisions or absence. Inverse commands also undergo current permission and data-integrity checks.

If an affected resource was changed after your transaction, Undo must not overwrite that later version. It reports conflicts such as a changed record, a missing record, or an item that now exists when absence was expected. A conflict disables execution until the stored entry validates again; it is not permission to force a restore.

Product Atlas Collaboration Example

1. You rename Aster Pro to Aster Pro 2 and receive an Undo entry.
2. Another Editor then changes the same resource's metadata.
3. Hover Undo after synchronization and inspect its validation result.

Expected result: the later revision makes the receipt conflict. The app does not restore your earlier metadata over the other Editor's work. Review the current resource and make a deliberate new edit if an agreed correction is needed.

Undo is validated when the entry is restored, after live synchronization, when the window regains focus, and immediately before execution. A previously available button can become conflicted as new data arrives. Failed inverse execution does not mean that all later changes can safely be ignored.

Current Permission Is Required

Undo does not preserve the permissions you had when you made the original change. The current signed-in user must own the receipt and still be authorized for the inverse operation. A demoted or removed user cannot use a historical receipt to bypass today's access rules.

Example: an Analyst can create a Product Atlas Table and may receive a receipt whose inverse deletes that View. Undo remains subject to the checked saved-View permission contract. A receipt belongs to that Analyst, not to another account using the same device.

Layer-only access is not a promise that every contextual transaction will validate as globally undoable. Rely on the current receipt and validation result, not the presence of Editor rights in one Layer.

Lifetime And Browser Scope

• One versioned receipt is stored per user in the current browser tab's session storage.
• It can survive navigation and reload in that tab while compatible and unexpired.
• It is not shared across devices, browsers, or a general cross-tab action history.
• Receipts expire 24 hours after creation.
• Sign-out, user change, successful Undo, incompatible/invalid receipt handling, and successful receipt-clearing operations remove the entry.
• If browser storage fails, the app warns that Undo is available only until the page is reloaded.

An expired entry can display an error rather than simply disappearing; it cannot be executed successfully. Undo is deployment-dependent and may be unavailable even for a command with inverse support. An administrator cannot make it universal merely by enabling the feature.

Failed Forward Actions And Refreshes

A failed forward transaction preserves the previous receipt in the shared executor. That entry still describes the previous successful supported transaction, not the failed attempt. Review the summary before clicking.

Example: you save a supported View update, then attempt a resource rename that fails a revision check. Undo may still refer to the View update. It does not undo the failed rename, which never completed.

An error while refreshing after a successful write is different from a failed write. Inspect authoritative data before resubmitting. Similarly, if an Undo request times out, inspect whether its inverse already committed before treating a retry as necessary.

Troubleshooting

Undo executes the complete inverse plan atomically and does not call the assistant again. There is no partial selection, previous-action browsing, redo, backup recovery, or restoration guarantee for deleted data. For high-impact operations, inspect the source workflow and its limitations first, especially Snapshots and the AI Assistant.