> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/basics/revert-version-history.md).
# Revert Version History
## Plan Gates and Access
Version History is gated by the builder account's active plan or configured entitlement.
Read this section first. It explains whether a builder can use the feature, how many previous versions are retained, and what happens when a plan does not include Version History.
| Plan or entitlement | Previous published versions retained | Can view previous versions? | Can revert? |
| ------------------------------------------ | -----------------------------------: | ------------------------------------- | ------------------------------------- |
| Free | 0 | No | No |
| Plus / Tier 1 | 0 | No | No |
| Pro | 1 | Yes | Yes |
| Premium | 3 | Yes | Yes |
| Enterprise | 6 | Yes | Yes |
| Custom without version-history entitlement | 0 | No | No |
| Custom with version-history entitlement | Entitlement-defined limit | Yes, when the limit is greater than 0 | Yes, when the limit is greater than 0 |
| Inactive, expired, or trial-only account | 0 | No | No |
{% hint style="info" %}
The current live version is always retained. It does not count against the previous-version limit.
{% endhint %}
{% hint style="warning" %}
Version History uses retention limits, not just visibility limits. Older archived versions beyond the active plan or entitlement limit may be pruned and may no longer be available for revert.
{% endhint %}
### Previous Version Limits by Plan
If the current live app is Version 10, the available previous versions depend on the plan.
| Plan | Available previous versions |
| ---------- | ----------------------------- |
| Pro | Version 9 |
| Premium | Versions 9, 8, and 7 |
| Enterprise | Versions 9, 8, 7, 6, 5, and 4 |
If fewer previous versions exist than the plan allows, the builder sees only the versions that are available.
### Locked Plans
Builders on Free, Plus / Tier 1, inactive, expired, trial-only, or Custom plans without an entitlement cannot revert to previous versions.
In the builder, they may see an upgrade or locked state instead of a list of revertible previous versions.
The product copy may say:
> Version History revert is available on Pro, Premium, and Enterprise plans.
Or:
> Upgrade to retain previous published versions and revert both the live app and draft builder state.
{% hint style="danger" %}
The backend enforces these plan gates. The frontend is not the source of truth for eligibility, ownership, or version access.
{% endhint %}
### Custom Plan Entitlements
Custom plans do not receive Version History access by default.
A Custom plan can access Version History only when an explicit version-history entitlement is configured for the account or organization.
When configured, the entitlement defines the number of previous versions retained and available for revert.
### Downgrades and Expired Plans
If an account downgrades, expires, or loses a Version History entitlement, its previous-version retention limit may decrease.
For example:
* Enterprise to Pro may reduce retained previous versions from 6 to 1.
* Premium to Free may reduce retained previous versions from 3 to 0.
* Custom with entitlement to Custom without entitlement may reduce retained previous versions to 0.
Older archived versions outside the new limit may be pruned.
## Overview
Version History lets eligible NotionApps builders restore an app to a previous published version.
Use this feature when a builder:
* Publishes changes by mistake.
* Breaks part of a live app.
* Needs to return the builder draft to a known working state.
* Needs the live app and builder state to match a previous published version.
When a builder reverts to a previous version, NotionApps restores the selected version into the builder and publishes it as the new live app. The revert is recorded as a new published version.
{% hint style="warning" %}
Reverting is a destructive restore for the NotionApps app configuration. Draft changes and published changes made after the selected version will be overwritten.
{% endhint %}
{% hint style="info" %}
The current app URL is preserved during revert. Reverting does not roll the app URL back to an older URL that may have existed in the selected version.
{% endhint %}
## What Version History Restores
Version History restores the NotionApps app configuration saved in the selected published version.
This can include:
| Restored item | What this means |
| -------------------------------- | --------------------------------------------------------------------------------------------------- |
| App name and description | The app name and description return to the selected version's saved state. |
| App icon and theme settings | Visual app settings saved with the selected version are restored. |
| App customization | Versioned app customization settings are restored when included in the saved app configuration. |
| Navigation and screens | The app's screen structure and navigation return to the selected version's state. |
| Sheet references used by the app | The app returns to the saved sheet and screen references in the selected version. |
| Personalization settings | Versioned personalization settings are restored when included in the saved snapshot. |
| User authentication settings | Versioned user access and authentication settings are restored when included in the saved snapshot. |
| In-app actions | Saved in-app action configuration is restored when included in the version snapshot. |
| App-level settings | Saved app behavior settings are restored when included in the version snapshot. |
| Live published app | The selected version becomes the basis for a new live version. |
| Draft builder state | The builder draft is updated to match the restored version. |
## What Version History Does Not Restore
Version History does not restore everything connected to an app.
It does not restore:
* Deleted Notion databases.
* Deleted Notion pages.
* Deleted Notion records.
* Deleted Notion properties.
* Billing settings.
* Account settings.
* Analytics.
* App ownership.
* Custom-domain ownership.
* Older app URLs.
* External data that no longer exists outside NotionApps.
{% hint style="danger" %}
If a Notion database, page, record, or property was deleted directly from Notion, reverting the app in NotionApps does not recreate that deleted Notion data.
{% endhint %}
## Before You Begin
Before reverting, confirm the builder understands the impact.
The builder should:
1. Confirm they are working in the correct app.
2. Confirm their plan allows Version History.
3. Review the current live app.
4. Review any draft changes in the builder.
5. Identify the version they want to restore.
6. Understand that newer draft and published changes may be overwritten.
7. Confirm that required Notion data still exists in Notion.
{% hint style="warning" %}
If the builder has unpublished work they still need, they should document it before reverting. The revert updates both the builder draft and the live app.
{% endhint %}
## Where to Find Version History
Version History appears in the app builder settings area.
To find it:
1. Open the app in the NotionApps builder.
2. Go to **Settings**.
3. Scroll through the app settings sections.
4. Find **Version History**.
The Version History panel appears with other app-level settings in the builder.
## Understanding the Version History Panel
The Version History panel includes a header, action buttons, and version rows.
### Header
The header shows:
* **Version History** as the section title.
* A short description of the feature.
* A **Refresh** button.
* A **Show versions** or **Hide versions** button.
If the builder's plan can revert versions, the description explains how many previous published versions are retained.
Example:
> Revert this app to one of the last 3 published versions. Reverting restores both the live app and the draft builder state.
If the plan does not include Version History, the panel explains that the feature is available on eligible paid plans.
### Refresh
Use **Refresh** to reload the version list.
This is useful after publishing, after reverting, or if the list failed to load.
While the list is loading, the button may show:
> Refreshing...
### Show Versions and Hide Versions
Use **Show versions** to expand the panel.
Use **Hide versions** to collapse it.
Collapsing the panel does not change version history. It only hides the details from view.
## Version Rows
When the panel is expanded, the builder may see:
* The current live version.
* Previous archived versions available under the current plan.
Each version row may include:
| Field | Meaning |
| -------------- | ------------------------------------------------------------------------ |
| Version number | The published version number, such as Version 10. |
| Status | Shows whether the version is **Live** or **Archived**. |
| Published date | The date and time the version was published. |
| Publish action | Shows whether the version was published manually or created by a revert. |
| Publisher | Shows who published the version when that information is available. |
| Revert button | Lets eligible builders restore an archived previous version. |
### Current Live Version
The current live version is shown for context.
The builder cannot revert to the current live version because it is already live.
### Previous Versions
Previous versions are archived published versions of the same app.
They are ordered from newest to oldest by version number.
### Reverted From Version X
If a version was created by reverting from an older version, the row may show:
> Reverted from Version X
This means the live version was created by restoring an earlier version.
For example:
1. Version 10 is live.
2. The builder reverts to Version 7.
3. NotionApps creates Version 11 as the new live version.
4. Version 11 may show **Reverted from Version 7**.
## How Reverting Works
Reverting does not simply mark an old version as live.
NotionApps performs a restore and publish process:
1. Verifies that the builder owns the app.
2. Checks whether the builder's plan can use Version History.
3. Checks which previous versions are available under the plan.
4. Verifies that the selected version is eligible.
5. Restores the selected version into the builder draft.
6. Publishes the restored draft.
7. Creates a new live version.
8. Archives the previous live version.
9. Keeps the selected source version archived while it is retained.
10. Prunes archived versions outside the active plan or entitlement limit when applicable.
{% hint style="success" %}
After a successful revert, the builder draft and live app should match the restored version.
{% endhint %}
## Example Revert
Suppose the current live app is Version 10.
The builder decides Version 7 was the last correct version.
When the builder reverts to Version 7:
| Version | Result |
| ------------- | ------------------------------------------------------ |
| Version 7 | Remains archived as the source version while retained. |
| Version 10 | Becomes archived. |
| Version 11 | Becomes the new live version. |
| Builder draft | Updates to match the restored version. |
| App URL | Remains the current app URL. |
The Version History panel may later show Version 11 as:
> Reverted from Version 7
## Revert an App to a Previous Version
{% stepper %}
{% step %}
## Open the app builder
Open the app that needs to be restored in the NotionApps builder.
{% endstep %}
{% step %}
## Go to Settings
In the builder, open **Settings**.
{% endstep %}
{% step %}
## Open Version History
Find the **Version History** section.
Select **Show versions**.
{% endstep %}
{% step %}
## Review the current live version
Review the **Current live version** row.
Use this row to confirm which version is currently live.
{% endstep %}
{% step %}
## Review previous versions
Under **Previous versions**, find the version to restore.
Review:
* Version number.
* Published date.
* Whether it was published manually or created by a revert.
* Publisher information, when available.
{% endstep %}
{% step %}
## Select Revert
Select **Revert** next to the previous version to restore.
If the **Revert** button is disabled, see [Troubleshooting](#troubleshooting).
{% endstep %}
{% step %}
## Read the confirmation message
The confirmation modal explains what will happen.
It warns that:
* The selected version will be restored as the current published app and draft builder state.
* Draft changes and published changes made after that version will be overwritten.
* The current app URL will be preserved.
* Deleted Notion databases, pages, records, and properties will not be restored.
* A new live version will be created to record the revert.
{% endstep %}
{% step %}
## Type REVERT
To confirm, type:
```
REVERT
```
The confirmation is case-sensitive. Type it in uppercase.
{% endstep %}
{% step %}
## Confirm the revert
Select **Revert**.
The button changes to:
> Reverting...
Do not refresh the page or close the browser while the revert is running.
{% endstep %}
{% step %}
## Wait for success
When the revert succeeds, NotionApps shows:
> Version reverted. Refreshing app data...
The builder reloads the app data so the restored state appears in the builder.
{% endstep %}
{% step %}
## Review the restored app
After the revert completes:
1. Review the builder draft.
2. Open the live app.
3. Confirm that screens, navigation, design, and app behavior match the intended previous version.
4. Confirm that the current app URL still works.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
The builder does not need to publish again immediately after a successful revert. The revert operation publishes the restored version as a new live version.
{% endhint %}
## After a Revert
After a successful revert:
* A new live version is created.
* The selected source version remains archived while retained.
* The previous live version becomes archived.
* The builder draft is updated.
* The live app is updated.
* The app URL remains the current URL.
* The Version History list refreshes.
If the builder makes additional changes after reverting, they should publish those changes as usual.
## Empty States
The builder may see an empty state when no previous published versions are available.
The panel may show:
> No previous published versions are available for this app.
This can happen when:
* The app has only one published version.
* Older versions have been pruned by retention rules.
* The account plan does not retain previous versions.
* The app has not been published enough times to create previous archived versions.
To create a previous version, the app must have at least one older published version behind the current live version.
## Locked or Upgrade State
If the account does not have access, Version History may show an upgrade message.
The panel may explain:
> Version History revert is available on Pro, Premium, and Enterprise plans.
Or:
> Upgrade to retain previous published versions and revert both the live app and draft builder state.
Backend access checks still apply even if a user attempts to call the API directly.
## Disabled Revert Button
A previous version may appear but not be revertible.
This can happen if:
* The version does not include the internal restore data needed to restore the builder draft.
* The version is outside the account's retained version window.
* The app data required for restore is missing or incompatible.
* The account no longer has access to enough previous versions.
If a version cannot be reverted, use a newer available version or contact support.
## Troubleshooting
### Version History could not be loaded
Message:
> Version History could not be loaded. Please try again.
What to do:
1. Select **Refresh**.
2. Check the internet connection.
3. Confirm the builder still has access to the app.
4. Refresh the browser page.
5. Try again later.
### Version revert failed
Message:
> Version revert failed. Please try again.
What to do:
1. Confirm that the app still exists.
2. Confirm that the account still owns the app.
3. Confirm that the plan still allows reverting.
4. Confirm that the selected version is still available.
5. Select **Refresh** in Version History.
6. Try the revert again.
If the failure continues, contact support.
### No previous versions are available
This usually means there is no eligible archived version to restore.
What to do:
1. Confirm that the app has been published more than once.
2. Confirm that the plan retains previous versions.
3. Confirm that older versions were not pruned by plan retention.
## Important Limitations
### Revert does not restore Notion data
Version History restores NotionApps app configuration. It does not recreate Notion databases, pages, records, or properties deleted from Notion.
### Revert does not restore older app URLs
The current app URL is preserved.
If an older version had a different app URL, that older URL is not restored.
### Revert does not restore custom-domain ownership
Custom-domain ownership and external domain records are preserved from the current app state.
### Revert does not compare versions
The first release does not include visual diffs between versions.
Review version dates and publishing metadata carefully before reverting.
### Revert is not collaborative branching
Version History is for restoring published app states. It is not a branching, release-labeling, or collaborative version-control system.
## Best Practices
Use these practices to reduce risk:
1. Publish intentionally.
2. Review the live app after every publish.
3. Use Version History soon after discovering a bad publish.
4. Check the selected version number before confirming.
5. Remember that revert creates a new live version.
6. Review the restored builder draft after reverting.
7. Test the public app URL after reverting.
8. Document major publishes outside the app if the team needs release notes.
{% hint style="warning" %}
Do not use Version History as a replacement for careful publishing review. It is a recovery tool, not a full release management system.
{% endhint %}
## Frequently Asked Questions
Does reverting change my public app URL?
No. The current app URL is preserved.
Does reverting change my custom domain?
No. Current custom-domain ownership and linkage are preserved.
Does reverting restore deleted Notion records?
No. Deleted Notion records are not restored.
Does reverting restore deleted Notion properties?
No. Deleted Notion properties are not restored.
Does reverting restore the builder draft?
Yes. A successful revert restores both the builder draft state and the live published app.
Do I need to publish after reverting?
No. The revert operation publishes the restored draft as a new live version.
Can I revert to the current live version?
No. The current live version is already live and is shown for context only.
Why can I see only one previous version?
The plan may retain only one previous version. Pro accounts retain one previous published version.
Why can I see three previous versions?
Premium accounts retain three previous published versions.
Why can I see six previous versions?
Enterprise accounts retain six previous published versions.
Why do older versions disappear?
Older archived versions beyond the active plan or entitlement limit may be pruned.
What happens if I downgrade?
The retained previous-version limit may decrease. Older archived versions beyond the new plan limit may be pruned.
Can support restore a version that is no longer retained?
Version History exposes retained versions. If a version has been pruned, it may no longer be available through Version History.
Can I cancel a revert while it is running?
No. After confirming the revert, wait for it to complete.
Why do I have to type REVERT?
The typed confirmation helps prevent accidental restores. Reverting can overwrite newer draft and published changes.
## Glossary
| Term | Meaning |
| -------------------- | ------------------------------------------------------------------------------------ |
| Current live version | The version currently published and served to app users. |
| Previous version | An archived published version of the same app. |
| Archived version | A published version that is no longer live but may be retained for history. |
| Revert | Restore a previous version into the builder and publish it as a new live version. |
| Restore data | Internal saved data used to restore the builder draft state. |
| Published app | The live app that end users can open. |
| Draft builder state | The editable app state shown in the NotionApps builder. |
| Retention limit | The number of previous archived versions retained by the active plan or entitlement. |
## Quick Reference
| Task | Action |
| ------------------- | -------------------------------------------------------------------------- |
| Check eligibility | Review the plan gates table at the top of this page. |
| View versions | Open **Settings**, find **Version History**, and select **Show versions**. |
| Reload version list | Select **Refresh**. |
| Revert a version | Select **Revert** beside an archived previous version. |
| Confirm revert | Type `REVERT` and select **Revert**. |
| Check result | Review the builder draft and live app after success. |
| Understand limits | Check the plan's previous-version retention limit. |
## Support Checklist
When contacting support about Version History, include:
* App name.
* App URL or app ID.
* Current live version number.
* Version number attempted for restore.
* Time of the attempted revert.
* Error message, if any.
* Whether the app's connected Notion data still exists.
* Account plan.
This information helps support determine whether the issue is access, retention, missing restore data, ownership, or a restore failure.