🔄Reload and sync
One sync manual. Workspace pages Reload Data (from app builder), Reload Data (from app), Automatic Reload Data, and Recovery History point here. Product help autoSync and reloadDataFromApp also point here.
What this is / when to use it
Pull schema + rows into the builder after a Notion change
Sync (builder Databases)
You only changed app layout — publish instead
Keep rows fresh on a schedule
Auto-sync
You need instant Notion→app on every keystroke
Let a signed-in user pull fresh rows
End-user refresh
Guests on a public list you do not want to hammer
Undo a bad sync / restore a snapshot
Rollback (Recovery History)
You meant to revert a published app version — that is Version History
Sync = builder ← Notion (schema and data).
Publish = users ← builder.
Refresh = live app ← Notion (rows).
Rollback = builder data ← snapshot.Before you start
The integration can see the database.
You understand that sync can add, rename, or drop fields in the sheet map. Dropped fields break components. See Save failed.
Nobody else should be mid-publish in another tab (409 risk). See Save conflict.
Build it
Sync from the builder
Open Databases.
Select the database.
Click Sync / Reload.
Wait until properties and sample rows look right.
Open a screen that uses the database. Rebind any component whose property vanished.
Publish if end users should see new properties.
Automatic reload
Open Databases → the sheet → Auto-sync.
Turn it on. Frequency follows your plan meter (two-way / auto-sync interval).
Auto-sync refreshes rows. It is not a substitute for a manual sync after you add a property in Notion — still run a builder sync so the field map updates.
Reload from the published app
On a list or details screen, enable Show reload button when the builder offers it (also documented on Relations for nested lists).
Publish.
Users tap reload. The app fetches fresh rows for that sheet. It does not change your screen layout.
Page content
Show page content is a separate fetch from row properties. A row can be fresh while the embedded Notion page body is stale. Reload page content after you share the page with the integration. Unsync reasons: page not shared, empty, or blocks failed to transform.
Rollback / Recovery History
Open Recovery History (workspace / databases).
Pick a snapshot from before the bad sync.
Restore. Confirm the field map matches the components you still have.
If the app definition is wrong, use Version History instead of Recovery History.
Every control
Sync / Reload
Manual
Rebuilds sheet fields from Notion.
Auto-sync
On / off + plan interval
Scheduled row refresh.
End-user reload
Button on screen
User-triggered row refresh.
Recovery History
Snapshots
Rollback synced data/schema snapshots.
Page content reload
Separate fetch
Notion block body for Show page content. Unsync reasons: page not shared, empty, or blocks failed to transform.
Nested list reload
On relation components
Refresh related rows only.
What users see
Users never see “sync” unless you give them a reload button. They see stale or fresh rows. After you sync a breaking schema change and publish, they see missing fields or failed writes until you fix the map.
Limits and plans
Usage meters that touch this page: databases, pages, properties, blocks, two-way sync frequency. See Plans.
Auto-sync interval is slower on lower plans.
Page content is not the same payload as row properties. A row can be fresh while the embedded page is stale.
Rollback does not delete the Notion pages that were created in the meantime.
Example
You add a Delivered file (files) property in Notion, then rename it. Components still point at the old field id. Builder autosave returns NoFieldInSheet. Fix: sync, rebind the file component to the new property, save, publish. If sync made it worse, rollback the snapshot, then rebind.
Fix problems
Databases missing
Not shared
Share with the integration.
Auto-sync “on” but schema stale
Auto-sync is rows, not properties
Manual sync.
Page content empty
Unshared page or transform fail
Re-share. Reload page content.
Related
Notion property types. Version History. Next on the maker path: Data restriction vs filters.