⏱️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.
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
The current live version is always retained. It does not count against the previous-version limit.
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.
Previous Version Limits by Plan
If the current live app is Version 10, the available previous versions depend on the plan.
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.
The backend enforces these plan gates. The frontend is not the source of truth for eligibility, ownership, or version access.
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.
Reverting is a destructive restore for the NotionApps app configuration. Draft changes and published changes made after the selected version will be overwritten.
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.
What Version History Restores
Version History restores the NotionApps app configuration saved in the selected published version.
This can include:
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.
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.
Before You Begin
Before reverting, confirm the builder understands the impact.
The builder should:
Confirm they are working in the correct app.
Confirm their plan allows Version History.
Review the current live app.
Review any draft changes in the builder.
Identify the version they want to restore.
Understand that newer draft and published changes may be overwritten.
Confirm that required Notion data still exists in Notion.
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.
Where to Find Version History
Version History appears in the app builder settings area.
To find it:
Open the app in the NotionApps builder.
Go to Settings.
Scroll through the app settings sections.
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:
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:
Version 10 is live.
The builder reverts to Version 7.
NotionApps creates Version 11 as the new live version.
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:
Verifies that the builder owns the app.
Checks whether the builder's plan can use Version History.
Checks which previous versions are available under the plan.
Verifies that the selected version is eligible.
Restores the selected version into the builder draft.
Publishes the restored draft.
Creates a new live version.
Archives the previous live version.
Keeps the selected source version archived while it is retained.
Prunes archived versions outside the active plan or entitlement limit when applicable.
After a successful revert, the builder draft and live app should match the restored version.
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 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
Select Revert
Select Revert next to the previous version to restore.
If the Revert button is disabled, see Troubleshooting.
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.
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.
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:
Select Refresh.
Check the internet connection.
Confirm the builder still has access to the app.
Refresh the browser page.
Try again later.
Version revert failed
Message:
Version revert failed. Please try again.
What to do:
Confirm that the app still exists.
Confirm that the account still owns the app.
Confirm that the plan still allows reverting.
Confirm that the selected version is still available.
Select Refresh in Version History.
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:
Confirm that the app has been published more than once.
Confirm that the plan retains previous versions.
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:
Publish intentionally.
Review the live app after every publish.
Use Version History soon after discovering a bad publish.
Check the selected version number before confirming.
Remember that revert creates a new live version.
Review the restored builder draft after reverting.
Test the public app URL after reverting.
Document major publishes outside the app if the team needs release notes.
Do not use Version History as a replacement for careful publishing review. It is a recovery tool, not a full release management system.
Frequently Asked Questions
Does reverting change my custom domain?
No. Current custom-domain ownership and linkage are preserved.
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 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.
Why do I have to type REVERT?
The typed confirmation helps prevent accidental restores. Reverting can overwrite newer draft and published changes.
Glossary
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
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.