> 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/databases/reload-and-sync.md).

# 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

| 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

1. Open Databases.
2. Select the database.
3. Choose Sync / Reload.
4. Read the health result; Partial or Held is not full success.
5. Confirm fields and sample rows.
6. Rebind components when a Notion property was removed/recreated.
7. Publish when users need the changed configuration.

### 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

A successful Sync can create Recalculate work, but it does not mean the final calculated value was written in the same request.

1. Share and sync child/related databases.
2. Sync the parent database.
3. Confirm the calculation is supported and enabled.
4. Allow asynchronous processing.
5. 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

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

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

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

| 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.                                           |

### Related

* [Recalculate calculated properties](https://docs.notionapps.com/how-to-guides/recalculate-calculated-properties)
* [Add/Remove users](https://docs.notionapps.com/users/add-remove-users)
* [9 Oct 2026 Release](https://docs.notionapps.com/release-notes/9-oct-2026-release)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.notionapps.com/databases/reload-and-sync.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
