Skip to content
NotionApps Docs

9 Oct 2026 Release

This cumulative release note covers features and backend improvements released after 4 Oct 2026 through 9 Oct 2026. It separates features makers can configure from reliability, security, and sync behavior that runs behind the scenes.

Available to makers

Mobile Monthly Calendar V1

Published NotionApps apps can now show a complete seven-column Month view on phones while keeping event titles usable at compact widths.

What users see:

  • One compact event title inside each populated day.
  • Long titles stay on one line and use an ellipsis instead of overlapping another date.
  • A localized +N more control appears when the day contains additional events.
  • Tapping +N more or the day number opens that date in Day view.
  • Tapping a visible event title opens that exact record when Open Item On Click is enabled.
  • If the calendar view switcher is hidden, Day drill-down includes Back to month.
  • Previous, Next, Today, Month, Week, Day, and Agenda continue to work.
  • Date-only, date-and-time, all-day, and multi-day records continue to use their existing date and time-zone rules.
  • Existing filters, search, personalization, data restrictions, languages, right-to-left layouts, and themes continue to apply.

How to enable Mobile Month

  1. Open a List (View Items), List (Update Items), or Select Items screen in Builder.
  2. Set View type to Calendar.
  3. Select a valid Date field and Title field.
  4. Set Default Mode to Month.
  5. Turn Show calendar view switcher on if users should be able to choose Month, Week, Day, or Agenda.
  6. Turn Open Item On Click on if tapping an event title should open its record.
  7. Validate one-event and multiple-event days in the mobile preview.
  8. Publish the app.

Existing Calendar screens use the same control and renderer; makers do not need to add a separate mobile-calendar component or configure a density setting.

For detailed date handling, interactions, preview checks, and troubleshooting, see View types (List, Grid, Calendar, Board).

Mobile Month V1 boundary

This release improves the in-app calendar inside a published NotionApps app. It does not add an iOS or Android home-screen widget, change the separate Notion Calendar product, add drag-and-drop calendar editing, or redesign the desktop calendar.

Maker-controlled email-and-password users

Makers can now add an authorized email-and-password user from Builder without enabling public signup. This closes the previous gap where allowing a new password user required opening signup to anyone who reached the app.

What makers can do:

  • Add a user by name and email from the Users area.
  • Assign an available role while adding the user.
  • Send or resend a secure invitation that lets the user create their own password.
  • See whether access is Not invited, Sent, Expired, Failed, Active, or Disabled.
  • See invitation, credential-provisioning, expiration, and password-established timestamps.
  • Send a password-reset email to an active user.
  • Disable access and re-enable it later.
  • Keep public signup off while inviting only named users.

NotionApps never shows the user’s password to the maker. The invited person establishes or resets it on a branded page associated with the published app.

How to add a controlled password user

  1. Configure the app as private and select Email & password as an authentication method.
  2. Connect and configure the Users database, including writable Name and Email fields.
  3. Keep public signup off if the app should be invitation-only.
  4. Open Users in Builder and choose Add User.
  5. Enter the person’s name and email, then select a role when roles are configured.
  6. Choose Add user and send invitation.
  7. Review the user’s Access state. If delivery fails or the link expires, use Resend invitation.
  8. After the user establishes a password, use Send password reset, Disable, or Re-enable as needed.
  9. Publish relevant app configuration changes; individual access actions take effect through the user-management flow.

Safer public password signup

For apps that intentionally keep public signup enabled, a new password signup must verify its email before the first password login completes. Existing user limits are checked before signup data is written, preventing an over-limit signup from leaving partial user data.

Changed on the backend

Password identity and access security

The controlled-user feature includes backend lifecycle protections, not only new Builder controls:

  • Invitation and password-reset actions use expiring, single-use codes.
  • Replayed, expired, or invalid links fail safely.
  • Authentication responses avoid revealing whether a credential belongs to an existing user.
  • Rate limits protect signup, sign-in, invitation, and reset paths from repeated attempts.
  • User limits are enforced before signup writes.
  • Email identities are normalized for consistent uniqueness checks.
  • Provisioning operations are idempotent so a retry does not create a second user.
  • Disabling a user, changing the synced credential, or changing access state invalidates existing sessions.
  • User rows and authentication identities are reconciled when the Users database syncs.

Duplicate-user sync compatibility

The controlled-user change exposed a compatibility issue for legacy Users databases containing repeated credentials. That behavior was corrected in the same release:

  • A repeated credential no longer aborts the entire sheet sync.
  • Existing active identities are preserved instead of being duplicated.
  • Inactive identities can be reconciled through the supported lifecycle.
  • The fix applies to both background sync and interactive backend API paths.

Recalculate reliability and recovery

Calculated-property processing received a broad reliability update covering formulas, rollups, queue pressure, MongoDB load, and controlled recovery:

  • Marker and edge work is bounded per tick so a large backlog cannot monopolize the database.
  • Child-marker record reads are batched to reduce repeated database round trips.
  • Formula work is protected when a dependent rollup is temporarily held.
  • Terminal formula outcomes stop recycling indefinitely through the retry queue.
  • Missing dependencies, terminal outcomes, evaluation failures, and ordinary retry conditions are classified separately.
  • Rollups can continue when current parent evidence proves that a previously missing relation is now complete.
  • Dependency catch-up continues in bounded passes instead of stalling the entire queue.
  • Computed blanks no longer repeatedly create duplicate recalculate signals.
  • Producer coalescing collapses duplicate signals before they inflate the active queue.
  • Blocked retry admission preserves capacity for active work while still allowing recoverable records to return safely.
  • Shared latency, health, work, and host-load signals can pause Recalculate before it harms customer-facing sync.
  • Durable telemetry reports queue state, retry classes, customer recovery, load latches, MongoDB operation budgets, and processing errors.

Database and API latency safeguards

Several query paths were changed to fail quickly or use bounded work rather than waiting on expensive database operations:

  • Record-sort aggregations no longer block indefinitely under MongoDB pressure.
  • Admin sync-latency queries use bounded execution time.
  • Latest-run sync-status lookups use bounded execution time.
  • Internal operations views can surface expensive-query and Recalculate recovery signals for diagnosis.

These are reliability changes; they do not add fields to a maker’s Notion database or require app reconfiguration.

What makers need to do

  • To use Mobile Month, select Calendar and set Default Mode to Month, then preview and publish.
  • To create an invitation-only password app, keep public signup off and add each authorized user from Builder.
  • Existing apps that do not use these features do not require a migration or configuration change.
  • No maker action is required for the Recalculate, database-query, or sync-compatibility safeguards.

Related