Restore or rollback: differences, limitations, and error states – Pythia Help Center

Restore and rollback solve different problems.

Use restore when a macro has been deleted. Use rollback when the macro still exists but needs to return to an earlier version.

Both features are available on the Pro plan.

Restore versus rollback

Restore a deleted macro

Restore:

is used for a deleted macro;
creates a new Zendesk macro;
assigns a new Zendesk macro ID;
leaves the deleted original unchanged;
creates a separate history chain for the restored macro;
links the restored macro to the deleted original in Macros Reporting and Management.

The same deleted macro can be restored more than once. Each restore creates another new Zendesk macro.

Roll back an existing macro

Rollback:

is used for a macro that still exists in Zendesk;
updates the existing macro;
preserves the same Zendesk macro ID;
creates a new latest history version;
leaves the selected earlier version unchanged;
preserves all newer history instead of removing it.

Which action should I use?

Use Restore as new macro when:

the original macro has been deleted;
you need to recreate its content in Zendesk;
receiving a new Zendesk macro ID is acceptable.

Use Restore this version when:

the macro still exists;
you need to return its content to an earlier state;
preserving the existing Zendesk macro ID is required.

Do not use restore as a substitute for rollback. Restore always creates a separate macro.

What restore does not preserve

Restore does not:

reactivate the deleted original;
reuse the deleted macro’s Zendesk ID;
append a new version to the deleted original’s history;
restore the macro’s previous Zendesk order.

After restoration, reorder the new macro separately when needed.

What rollback does not change

Rollback does not:

replace the macro with a new Zendesk record;
remove versions created after the selected version;
rewrite the existing history chain;
restore the macro’s Zendesk order.

A history version that contains only a reorder event cannot be rolled back. Use reorder mode to change macro position.

Versions that cannot be rolled back

Rollback is not available when:

the selected version is the current latest version;
the selected version contains only a position change;
the source version cannot be found;
the source version belongs to a different macro;
the source version is not restorable;
the current macro has been deleted;
the target macro no longer exists.

When the latest version is selected, the rollback button is not shown.

No changes to apply

A rollback can produce a No changes to apply result when the selected version already matches the current macro after the title and final-state settings are considered.

In this case:

Zendesk is not updated;
no new history version is created;
you can close the dialog;
you can change the rollback title or final state if one of those values still needs to be updated.

Stale previews

A restore or rollback preview can become stale when the macro changes after the preview is generated.

The app then asks you to refresh the preview and confirm the operation again.

Do not continue from an outdated preview. Review the refreshed content before applying the operation.

For rollback, the preview can also become stale when Zendesk differs from the latest state stored in Pythia. Synchronise the macro before trying again.

Validation and blocking issues

Restore or rollback can be blocked when the stored macro content references Zendesk resources that are no longer available.

Examples include:

deleted or unavailable custom fields;
unavailable custom-field options;
missing brands;
missing groups;
missing ticket forms;
unavailable users or assignees;
unsupported macro actions;
invalid or empty titles;
missing active-state information.

Restore can also be blocked when:

the source macro is no longer deleted;
no complete active snapshot exists from before deletion.

Review the blocking message in the dialog and correct the underlying Zendesk configuration before generating a new preview.

Operation already in progress

The app may report that a restore or rollback is already running or waiting for reconciliation.

This is not a retryable state.

You can close the dialog safely, but do not start the same operation again. Reopen the macro later and confirm its current state.

Failed operations

When a restore fails, the macro is not restored.

Refresh the preview before trying again.

When a rollback fails, close the dialog and reopen the rollback workflow to generate a fresh preview.

Do not repeatedly submit the same request from an old dialog state.

Uncertain Zendesk outcomes

In some cases, Zendesk may have received the operation, but the app cannot confirm the final result.

For restore, this can mean that Zendesk may have created the new macro.

For rollback, this can mean that Zendesk may have updated the existing macro.

When this happens:

do not retry from the current dialog;
check Zendesk first;
verify whether the macro was created or updated;
contact support with the IDs shown in the message if the result remains unclear.

Retrying without checking Zendesk can create a duplicate restored macro or repeat an update unnecessarily.

History and post-processing warnings

A restore or rollback can succeed in Zendesk while a later Pythia step fails.

Examples include:

the macro was created, but the Management table or search index did not refresh;
the macro was created or updated, but the history record could not be completed.

When the interface says that Zendesk succeeded but history or indexing failed:

do not retry automatically;
confirm the macro in Zendesk;
refresh Macros Reporting and Management;
contact support if the macro or its history remains inconsistent.

Only successfully completed restore and rollback operations are guaranteed to appear normally in macro history.

Unrecognised operation states

The app may occasionally receive an operation status it does not recognise.