> 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/release-notes/3-oct-2026-release.md). # 3 Oct 2026 Release This release adds a **Scheduling date** component for booking screens and replaces silent row removal with **sync holds** you decide on, alongside login, builder, and live-demo fixes. On the backend it rebuilds the **Recalculate** engine onto its own server and starts a guarded rollout, and closes a run of sync reliability fixes shipped between 17 Sep and 3 Oct. The note is split in two. **Available to makers** covers what you can open and use in the builder or the published app today. **Changed on the backend** covers work that shipped on the servers; there is nothing new to click for those items, and they are listed so you know what changed under your app. {% hint style="info" %} Earlier updates For the Calculated properties tab and the per-field Recalculate toggle, see the [16 Sep 2026 Release](https://docs.notionapps.com/release-notes/16-sep-2026-release). {% endhint %} *** ### What’s in this release **Available to makers now** | Capability | What you can do | Learn more | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Scheduling date | Add a date field to a form that hides closed days, holidays, and out-of-hours times, in your time zone | Section 1 · [Add/Update data components](https://docs.notionapps.com/screens-and-components/type-of-components/add-update-data-components#scheduling-date-rules) | | Sync holds | When a Notion read comes back short, rows are held instead of deleted. You choose **Keep these rows** or **I removed these in Notion** | Section 2 · [Reload and sync](https://docs.notionapps.com/databases/reload-and-sync) | | Recalculate switch | The per-field switch from 16 Sep now updates its status line on save and is honored by the engine | Section 3 | | Login and forms | Email & password can use the email column, and tall sign-up forms no longer clip the password field or submit button | Section 4 | | Builder and live demo fixes | First filter on related lists, mobile create links, **Create New App** on `/home`, **Get demo code** | Sections 5–6 | **Changed on the backend (no setting, no maker action)** | Area | What was done | Learn more | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | Recalculate engine | Moved to its own server, computes rollups past Notion’s 25-page limit from the synced graph, keeps a good number once computed, and is rolling out to apps in stages behind a guarded canary | Section 7 | | Sync reliability | Rate-limited writes retry, very large databases get up to 3 hours to read, polling recovers on its own, and a write for a deleted row no longer blocks the database | Section 8 | | Support and operations | Support sees the same sync hold you see and can record the same two choices; Recalculate health is visible in Live Operations | Section 9 | ``` Scheduling date: the calendar hides what the rules forbid; save checks the same rules again. Sync hold: nothing is removed until you say so, and then only on the next complete read. Recalculate: rebuilt on the backend and rolling out in stages. Nothing for you to turn on. ``` {% hint style="success" %} Start here Booking screens: add a **Scheduling date** field and fill **Closed days**, **Hours**, and **Time zone**. Missing rows after a sync: open **Settings → Data → Sync Health** and look for `not in Notion`. Rollups that stop at 25: no action; leave **Recalculate in NotionApps** on and the backend rollout reaches your app in stages. {% endhint %} *** ### Available to makers #### 1. Scheduling date **Before.** A booking or appointment form used a plain **Date picker**. Any day and any time could be chosen, so makers wrote instructions above the form (“weekdays only, 9 to 5”) and still received bookings on Sundays, on holidays, or for the same afternoon. The only fix was a Notion automation or a manual decline after the fact. **Now.** **Scheduling date** is a new field type for forms. It carries its own rules, so two date fields on one screen can keep different calendars (a pickup date and a return date, for example). The end user sees an ordinary calendar; days and times that break the rules are simply not offered. When they press save, the server checks the same rules again, so a stale browser tab or a hand-edited request cannot slip a closed slot through. Open the field in the builder, choose **Scheduling date**, and fill the **Scheduling rules** section. Every box is optional. Leave a box blank to skip that rule. | Rule | What it does | Example | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Closed days** | Tap a weekday to close it. Closed days are highlighted. Sunday is the first day of the week. Leave every day off to allow all seven. | Close **Sat** and **Sun** for an office that books Monday to Friday | | **Holidays** | One date per line, written as `YYYY-MM-DD`. Add `yearly` after a date to block that month and day every year. No national holiday calendar is loaded; you list the days that matter to you. | `2026-11-26` blocks one Thanksgiving; `2026-12-25 yearly` blocks every Christmas | | **Earliest day** | How many days from today before someone can book, counted in the field’s time zone. `0` allows today. `1` makes tomorrow the first open day. | `2` for a caterer who needs two days’ notice | | **Booking window** | How many days ahead someone can book, counted from today. Blank means no far limit. | `14` offers the next two weeks and nothing beyond | | **Hours** | One range per line in 24-hour time, like `08:00-16:30`. Add weekdays after the range to limit it, where `0` is Sunday and `6` is Saturday. Leave blank to allow the whole day. If you add hours, set **Show date/time** above to date and time so the picker asks for a time. | `08:00-16:30 1,2,3,4,5` is Monday through Friday office hours; a second line `10:00-13:00 6` adds Saturday mornings | | **Time zone** | Closed days, the earliest day, and the hours all use this zone, not the end user’s browser zone. | `America/New_York` | What the end user sees: * The calendar greys out closed weekdays, holidays, days before the earliest day, and days past the booking window. * When hours are set, a weekday stays selectable until a clock time is chosen; only times inside the allowed range are offered. An earlier version rejected the day itself whenever a time range existed, which greyed out Monday through Friday. That is fixed. * If a saved value breaks a rule anyway, the form shows one of: **That day is before the first available day.** / **That day is outside the booking window.** / **That weekday is closed.** / **That day is a holiday on this field.** / **That day has no available hours.** / **That time is outside the available hours.** * The calendar popup has a solid background, so the form underneath no longer shows through it. Builder notes: * Each rule has a help bubble that explains the format, so you no longer need to remember weekday numbers. * Switching the field to **Date picker** and back keeps the rules and the date/time choice. Saving a field as a normal **Date picker** does not erase rules you typed earlier. #### 2. Sync holds instead of silent removal **Before.** A sync read that came back short, because Notion timed out, rate-limited, or returned an incomplete page list, could be treated as “these rows are gone” and remove them from the app. Makers found rows missing with no sign of why, and the only remedy was a full reload. **Now.** Deleting rows after a read is gated in two steps on the backend (details in Section 8), and the decision is yours. 1. **Short reads never delete.** If the read was partial, hit a row or query cap, ended early, or could not resolve a partition, nothing is removed. The app waits for a complete read. 2. **A complete read that is still missing many rows goes on hold.** If 100 or more rows are missing, or 10 % or more of a database with at least 100 rows, NotionApps holds the database instead of deleting. Only a small, ordinary number of missing rows (a few pages you archived in Notion) is removed automatically. In **Settings → Data → Sync Health** a held database shows `N not in Notion` next to its health caption and two buttons: | Button | Result | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Keep these rows** | Rows stay in the app. The caption reads **Keeping these rows until you change it.** You can switch to the other choice later from the same row. | | **I removed these in Notion** | The rows are removed on the next *complete* read. The caption reads **Removal runs on the next complete sync.** A partial read does not spend your decision, so a flaky Notion response cannot turn your answer into a half-deletion. | The decision is recorded with who made it and when. **Sync now**, **Retry**, **View details**, and **Create ticket** stay available on the same row. #### 3. Recalculate switch and status line The per-field **Recalculate in NotionApps** switch shipped on 16 Sep under **Databases → Calculated properties**. Two things about it changed in the builder: * **The status line updates on save.** Flipping the switch now changes **We’ll recalculate this** / **Using Notion’s value** immediately. Before, the checkbox moved but the text kept the old value until reload. * **The switch is honored end to end.** A field turned **off** is left out of recalculation and keeps Notion’s page value. Nothing is computed for fields you did not ask for. Formula-only databases stay in scope. What the switch can evaluate is unchanged from 16 Sep: `prop()`, the four arithmetic operators, `if()`, `and`, `or`, `not`, `empty`, `now`, `dateBetween`, and simple literals for formulas; `sum`, `count`, `average`, `min`, and `max` for rollups. Unsupported recipes show **Can’t recalculate** with the token named, and Notion keeps the number. The switch does not turn the engine on for your app. The engine is a backend rollout (Section 7). Leaving the switch on means your fields are included when the rollout reaches your app. #### 4. Login and forms * **Email & password with the email column.** In **Users** setup, the login-method picker treated every method other than *email code* as a phone login, so choosing **Email & password** with an email column left **Confirm** disabled. Email & password now accepts the email column and confirms. * **Tall sign-up forms.** A mobile-view app opened in a desktop browser locked the auth card to a phone frame. A sign-up form with name, email, password, and confirm fields overflowed, and the password field and submit button were cut off with no way to scroll. The card now grows with the form, the form scrolls inside the phone frame when it must, and desktop login clicks land on the card while the frame is still resizing. * **Labels stay put.** Field labels no longer unmount while the submit button shows its loading state, so the form does not jump or lose focus mid-submit. #### 5. Builder fixes * **Related lists accept a first filter again.** After nested filter groups shipped, **Add Filtering** on an update-data control did nothing when the list had no filter yet, because the replace step was skipped when filtering was missing. The first filter now saves. * **Mobile create links keep auto-link ids.** When a create screen is opened from a related list on mobile, the URL carries the reference that links the new record back to the parent. That reference was being dropped on the round trip, so the new record was created unlinked. It is kept intact now. * **Create New App no longer crashes on `/home`.** Calculated-property captions tried to read builder state that does not exist on the Home page and took **Create New App** down with them. The captions now guard that case. * **Manage Databases copy.** The empty-list hint now says what to do: a database missing from the list has not been shared with NotionApps yet; click **Manage Databases** to share more Notion pages, select the databases, then click **Build App**. #### 6. Live demo * **Get demo code stays visible.** If the first fetch of the demo list failed, the **Get demo code** button disappeared. The list now retries, and the button stays. * **Shared demo personas recover from code limits.** When a shared demo persona hit the one-time-code limit, the demo locked for everyone using it. The persona now recovers instead of staying locked. *** ### Changed on the backend These items shipped on the NotionApps servers between 17 Sep and 3 Oct. There is no setting for any of them and nothing for a maker to do. They are here so the behaviour of your app, and the numbers it shows, can be traced to a change. #### 7. Recalculate engine **Before.** The 16 Sep release let you choose **Recalculate in NotionApps** per field, and the value was computed inside the sync workers. In practice the published app often kept showing Notion’s stored page value, rollups still stopped at the 25 linked pages Notion’s page API returns, and a slow recalculation pass could delay saves and syncs on the same host. The Databases tab said *We’ll recalculate this* while Home still showed `0/600`. **What was done.** * **Its own server.** Recalculation now runs as a separate process on a dedicated host, so a long compute never delays a save or a sync. The sync workers no longer start the drain. * **Rollups past 25 from the synced graph.** After a database syncs, the engine pages through relations Notion returned incomplete and stores the linked rows beyond the first 25. Rollups are computed from the stored child edges rather than from Notion’s capped page, so sums, counts, averages, minimums, maximums, and hour totals can cover the whole related list and match Notion’s UI instead of Notion’s API. * **Home serves the computed number.** Where a value has been computed, published screens serve NotionApps’ evaluation of the recipe. Fields that depend on that field are re-run from the computed value, and the list sync no longer writes Notion’s stored leaf back over it. * **A good number stays.** Once a value is computed, a later sync does not overwrite it with Notion’s 25-capped leaf. A parent is re-queued only when one of its recipe inputs actually changed, so a Notion refresh that changed nothing does not churn the number. A parent whose own child list is still syncing is held rather than written as zero or a partial sum. * **Linked totals update when children finish.** When a child database finishes syncing, the parents that roll it up are queued once, instead of waiting for a full walk of the child database. List sync marks only the child rows that changed, and the recalculate host consumes those markers. * **Formulas the engine cannot parse take Notion’s value.** A hold meant for recalculated fields had frozen every formula, so a status Notion had already updated never reached the app. Unsupported formulas now flow through from Notion again, and list sync no longer queues formulas the engine cannot write. * **Blank formulas fill from local clock times.** A formula that only needs clock-time arithmetic (for example hours between a start and an end) is evaluated from the values already in the app instead of showing blank until Notion returns a value. `dateBetween(date1, date2)` now follows Notion’s order, date1 minus date2. * **Self-protection.** Before each pass the engine checks Mongo latency, work timeouts, and sync-host load. Three strikes on any of them pauses the engine; a single slow query no longer turns it off. When it pauses, Sync keeps running and the last computed number stays on Home. Edge writes go out in small batches so one long write cannot trip the pause, and the queue is capped so a backlog cannot grow without bound. **Where it stands today.** The engine is on in production behind a **guarded canary**. As of 3 Oct it is computing for a fixed 5 % slice of parent rows, chosen deterministically so the same rows stay in the slice between passes. Every 30 minutes, with at least 100 samples, it checks its own health: errors, stale heartbeats, or unsafe host load block promotion and, if repeated, roll the slice back; a clean window with acknowledged work and a queue that is not above its baseline promotes it to the next stage, up to all rows. Promotion and rollback happen on the server; there is no maker-facing switch. **What this means for your app right now.** * Most apps still show Notion’s page value for rollups over more than 25 linked pages. That is expected while the slice is small. * Leave **Recalculate in NotionApps** on for the fields you want included. When the rollout reaches your rows, Home starts serving the computed number without a republish. * Nothing you do in the builder speeds this up. **Sync from Notion** stores the linked rows past 25 (that part of the work is live for every app), but the rollup itself is computed only when your rows are in the slice. * If a number looks wrong in the meantime, the 16 Sep guidance still applies: turn the switch **off** for that field to show Notion’s value. A later release note will say when the rollout has reached all apps. #### 8. Sync reliability * **Rate limits.** When Notion answered a write batch with 429, the batch was marked done and the watermark moved on, so the row stayed on **Sending** with no further attempts. Those writes are now scheduled to retry with a wait, and the database is picked up again when they are due. **Sending** turns into **Synced** on its own instead of waiting for a manual sync. * **Very large databases.** Long Notion reads were cut off at 30 minutes. A database with over a thousand partitions was killed about a quarter of the way through, never completed, and never scheduled its next read. Long reads now get up to 3 hours. * **Polling.** The sync scheduler used to stop quietly after certain transient errors and needed a restart. It now recovers and keeps polling. * **Deleted before it was sent.** When a row was deleted in the app before its create or update reached Notion, the pending write pointed at a row that no longer existed. The worker skipped it every pass but never closed it, so the database was selected for sync every couple of seconds and sent nothing. Deleting a row now cancels its unsent create and update, and the worker closes any stale write it finds. The database goes back to its normal schedule. * **Sync holds are persisted.** The hold described in Section 2 is stored with the database, with the decision, who made it, and when, and removal is applied only on the next complete read. Short and partial reads are classified on the server (partial page list, row or query cap, early end, unresolved partition) and never delete. * **Related lists store everything.** The relation paging described under Recalculate also means related lists in screens show rows past 25, not just rollup totals. * **Worker pool and waiting line.** Production sync workers were resized for the new sync host, share one waiting-line counter so list sync cannot fill past the cap, and skip reads while the host is under RAM or load pressure instead of piling them up. #### 9. Support and operations * **Live Operations sees the same hold.** A held database appears in Live Operations with the same two choices, **Keep these rows** and **I removed these in Notion**, so support can record the decision on a maker’s behalf and one audited decision applies no matter who made it. * **Recalculate health in Live Operations.** The rollout stage, the current slice, acknowledged and blocked counts, queue depth, and the strike counters that pause the engine are visible to support, along with a per-pass summary. * **Lighter Live Operations refresh.** Live Operations no longer pulls a week of sync runs on every refresh. * **Kill switches without a client release.** The login-label fix and the mobile auto-link fix can each be turned off on the server if a regression appears, without shipping a new client build. *** ### What makers need to change | Goal | Extra work | | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Booking form that refuses closed days or out-of-hours times | Add a **Scheduling date** field. Set **Closed days**, **Hours**, and **Time zone**. If you add hours, set **Show date/time** to date and time. | | Different calendars for two dates on one form | Give each **Scheduling date** field its own rules; they do not share. | | Rows missing after a sync | **Settings → Data → Sync Health** → **Keep these rows** or **I removed these in Notion**. Nothing is removed until you answer. | | Rollups or hours that stop at 25 linked pages | None you can take today. Leave **Recalculate in NotionApps** on; the backend rollout reaches your app in stages. | | Show Notion’s raw value for a field | Turn **Recalculate in NotionApps** off for that field. | | Writes stuck on **Sending** | None. Rate-limited writes retry on their own. | | Email & password login | Pick the email column in **Users** setup and confirm. | | Sign-up form cut off on desktop | None. Republish is not required; the fix is in the live client. | End users do not see any of these settings. They see a calendar that only offers open slots and rows that do not disappear without a decision. As the Recalculate rollout reaches an app, they also see rollup numbers that match Notion’s UI. *** ### Related * [Recalculate calculated properties](https://docs.notionapps.com/how-to-guides/recalculate-calculated-properties) * [Formulas & Rollups](https://docs.notionapps.com/screens-and-components/formulas-and-rollups) * [Why are my rollups showing zero or an incorrect value?](https://docs.notionapps.com/troubleshooting/why-are-my-rollups-on-notionapps-showing-zero-0-value-or-an-incorrect-value) * [Reload and sync](https://docs.notionapps.com/databases/reload-and-sync) * [Add/Update data components](https://docs.notionapps.com/screens-and-components/type-of-components/add-update-data-components) (Scheduling date rules) * [Settings → Data](https://docs.notionapps.com/settings/data) * [📢 Release Notes](https://docs.notionapps.com/release-notes) * [16 Sep 2026 Release](https://docs.notionapps.com/release-notes/16-sep-2026-release)