Your client opens a project portal. The layout looks right. The tasks are there. But the total hours do not match the number in Notion.
For the client, that is a trust problem. They should not have to understand an API to know whether a project total is complete.
One cause is a documented difference between what Notion displays in its interface and what its API returns to connected applications. As databases become more connected, that difference can affect the formulas and rollups your business relies on.
That is why we enhanced Recalculate in NotionApps: to evaluate supported calculations from synced records, rather than rely solely on the calculated value returned in a Notion page response.
The Notion API limitation behind a confusing total
Relations connect records across Notion databases. Rollups and formulas turn those relationships into useful information: total hours, quantities, averages, remaining balances, and other summaries.
But a standard Notion page response includes at most 25 related-page references. Notion also documents that, in data-source query responses, a formula depending on a relation with more than 25 references evaluates only 25. Calculations involving multiple layers of relations can have additional limitations. See Notion’s page response limits and formula and rollup limitations.
This does not mean your Notion database can contain only 25 related records. It means an application must account for the difference between a complete relationship and the information returned in a particular API response.
An illustrative example: 40 time entries, one project
Imagine a project linked to 40 time entries, each containing two hours of work.
| Records included in the calculation | Total hours |
|---|---|
| All 40 time entries | 80 |
| Only 25 time entries | 50 |
The second total looks reasonable. It is also missing 30 hours.
This is a simplified illustration, not a customer benchmark or a prediction that every affected API response returns 50. Depending on the calculation and response, the discrepancy may appear as an incomplete total, a blank result, or another unexpected value.
For a business app, the lesson is practical: successfully receiving a number does not establish that the number includes every required record.
What enhanced Recalculate does differently
Notion remains the place where you define your formula or rollup. You do not need to maintain a second copy of the calculation in a separate editor.
For supported properties, NotionApps imports the definition and evaluates it using the related records available through its synchronization system. That gives the app a way to calculate from the underlying data instead of simply displaying the value supplied in a capped page response.
The approach has three parts:
- Sync the inputs. Bring in the database records, relationship information, and calculation definition needed for the result.
- Evaluate supported calculations. Process the required inputs in the background, including supported dependencies between calculated fields.
- Keep the selected result visible. When Recalculate is enabled and succeeds, subsequent page loading preserves the computed value rather than replacing it with Notion’s stale page value.
For a supported rollup involving more than 25 related pages, this means NotionApps can work from the synced related records once the relationship and its inputs are complete. Every required database must be shared with the integration and synced. Recalculate cannot compensate for records it cannot access.
Our October Recalculate update explains the changes to calculated values and background processing in more detail.
Sync and Recalculate solve different problems
Sync brings the source data into NotionApps. Recalculate uses that data to evaluate supported formulas and rollups.
Those steps are connected, but they do not necessarily finish at the same moment. A sync can complete while background calculation is still waiting for a related database or processing earlier work.
When inputs are incomplete, retaining the last good result can be safer than overwriting it with an incomplete calculation. That result may remain temporarily old, so the property’s status matters when you investigate a discrepancy. A waiting state should prompt a check of the inputs and sync status, rather than an assumption that the calculation has finished.
This is especially useful for linked operational data, where a change to one time entry, order line, or inventory record can affect a summary elsewhere.
How this differentiates NotionApps
When comparing tools for Notion, it is easy to focus on templates, branding, forms, and how quickly a page becomes an app. Those matter. For operational applications, the calculation path matters too.
NotionApps combines a published app experience with an explicit choice about how supported calculated properties are evaluated. Makers can inspect the imported definition, see its dependencies and status, and choose Recalculate instead of using Notion’s page value.
| Approach | How a calculated value reaches the app | What to verify |
|---|---|---|
| Display the API-provided value | The application displays the value received from Notion | Whether the response includes the required relationship data and a complete calculation |
| Build a custom calculation pipeline | Your own integration retrieves inputs and calculates a result | Pagination, dependency ordering, retries, maintenance, and how the result reaches the app |
| Use NotionApps enhanced Recalculate | NotionApps evaluates a supported Notion definition from synced records | Recipe support, access to all required databases, complete inputs, and background processing status |
This is a comparison of approaches, not a claim that every competing product uses the first approach.
Comparing NotionApps with other app and website builders
Softr also offers portals and apps connected to Notion. Super focuses on publishing websites with Notion as the content source. Their product descriptions establish different capabilities and use cases; they do not, by themselves, demonstrate how a particular formula behaves with 40 related records.
For your shortlist, ask each provider to demonstrate the same calculation with more than 25 related pages, then change a source record and reload the published result. Ask how incomplete inputs, unsupported expressions, and delays are surfaced.
NotionApps’ specific differentiator is a built-in, maker-controlled recalculation path for supported Notion formulas and rollups, integrated with synchronization and the published app. That is a concrete capability you can evaluate against your own data.
Where this matters in everyday business apps
Consider an agency giving a client a portal with project hours, a warehouse summarizing quantities across transactions, or a service team showing work completed across many jobs. As the number of related records grows, an incomplete aggregate can become harder to spot by eye.
Enhanced Recalculate is relevant when those summaries use supported calculations and all required records are available to the app. It helps you address the calculation gap without asking every customer or employee to open the underlying Notion databases and manually check the total.
How to use Recalculate in NotionApps
- Share the parent database and every related database with the NotionApps integration.
- Sync the required databases, especially after changing a formula, rollup, relation, or target property in Notion.
- In the builder, open Databases → Calculated properties.
- Select the property and review its Notion recipe, Status, and Depends on information.
- Leave Recalculate in NotionApps on when the toggle is available for that property.
- Publish and allow background processing to complete.
- Verify the result in the published app, then reload it to confirm the result remains stable.
For an effective test, change one source value and check that the expected total updates after sync and recalculation. Include a record with more than 25 related pages if that reflects your real workload.
Follow the Recalculate setup guide for property states and troubleshooting.
Supported calculations and boundaries
Recalculate supports selected formulas and numeric rollups, including sums, counts, averages, minimums, and maximums. Formula support includes property references, arithmetic, comparisons, and supported conditional and date calculations.
It does not evaluate every expression in Notion’s formula language. Unsupported properties continue to use Notion’s value, and the builder explains why Recalculate is unavailable. Repeated sync cannot add support for an unsupported expression.
Processing is asynchronous, and safeguards can defer work. Recalculate also depends on shared, synced source data. It does not make every calculation instant or remove every API constraint. Check the current supported calculations and limitations when assessing your app.
Build the app and verify the numbers
A professional portal needs useful screens and reliable information. When a customer sees a total, they need confidence that it reflects the records behind it.
Enhanced Recalculate gives NotionApps makers another way to deliver that confidence: keep the definition in Notion, evaluate supported calculations from synced inputs, and verify the result in the app your customers actually use.
Already using NotionApps? Open Databases → Calculated properties and review the formulas and rollups your users depend on.
Building your first app? Explore NotionApps and test your real relationships and calculations as part of your setup.