Reload and sync
Sync imports Notion schema and rows into NotionApps. Publish sends Builder configuration to end users. Reload refreshes rows. Recalculate evaluates supported formulas and rollups after the required data is available. These are related but separate operations.
Which action to use
Section titled “Which action to use”| Goal | Action |
|---|---|
| Import a new/renamed Notion property | Builder Sync / Reload |
| Refresh Notion rows | Sync, auto-sync, or end-user reload |
| Make Builder layout changes live | Publish |
| Evaluate supported formulas/rollups | Enable Recalculate; sync dependencies; allow background processing |
| Restore a prior synced snapshot | Recovery History |
Sync from Builder
Section titled “Sync from Builder”- Open Databases.
- Select the database.
- Choose Sync / Reload.
- Read the health result; Partial or Held is not full success.
- Confirm fields and sample rows.
- Rebind components when a Notion property was removed/recreated.
- Publish when users need the changed configuration.
Sync and controlled users
Section titled “Sync and controlled users”The Users database also reconciles login identity state:
- New controlled password rows can be invited from Builder.
- Active or credential changes can invalidate stale sessions.
- Legacy duplicate credentials no longer abort the entire sheet sync; the existing active identity is preserved and unsafe duplicate provisioning is rejected.
Do not intentionally keep duplicate active email rows. Fix the Users database even though sync protects unrelated rows from the legacy collision.
Sync and calculated properties
Section titled “Sync and calculated properties”A successful Sync can create Recalculate work, but it does not mean the final calculated value was written in the same request.
- Share and sync child/related databases.
- Sync the parent database.
- Confirm the calculation is supported and enabled.
- Allow asynchronous processing.
- Reload the published app and verify the value.
Under load, queue and database safeguards can defer work. Last good values are retained; unsupported or incomplete recipes do not receive invented values.
Automatic and end-user reload
Section titled “Automatic and end-user reload”Auto-sync refreshes rows on the plan interval. It does not replace manual schema sync after adding a property. End-user reload refreshes the configured sheet but does not publish Builder changes.
Sync Health
Section titled “Sync Health”Use Settings → Data to inspect overall status, last success, active syncs, per-database issues, and recent history.
| Health | Meaning |
|---|---|
| Up to date | Complete read succeeded. |
| Partial | Read did not finish; extra local rows were kept. |
| Held | Large cleanup paused; nothing was removed. |
| Waiting | Writes are still sending/retrying. |
| Access blocked | Integration cannot read Notion. |
Short reads never delete rows. A complete read with a large missing set is held for the maker’s decision. Use Keep these rows or I removed these in Notion only after understanding the source change.
Query and timeout safeguards
Section titled “Query and timeout safeguards”Status, latency, and record-sort queries use bounded execution so an expensive diagnostic or aggregation does not hold customer operations indefinitely. A timed-out diagnostic may need retrying, but it does not mean data was deleted. Frontend static-generation requests are also bounded so one slow backend request cannot hold a deployment forever.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Action |
|---|---|
| Schema stale after auto-sync | Run manual Builder Sync. |
| Sync Partial | Retry later; extra rows remain. |
| Sync Held | Choose the correct cleanup decision; nothing is removed before it. |
| User row synced but invitation absent | Open Users and send invitation. |
| Formula stale after sync | Check Calculated properties, dependencies, and background processing. |
| Save remains Sending | Let the durable write retry; do not submit a duplicate. |
| Access blocked | Reconnect Notion and retry. |