I’m building a large client portal for a customer, on top of his Notion workspace. I’m using various list blocks in Softr, querying data from various Notion databases using multiple Record filters. We’ve noticed major synch delay differences between various use cases:
- edit page property in Notion database => update in Softr portal within 1 min
- add new page in Notion database => update in Softr portal within 1-3 min
- remove a page from a Notion database => update takes > 60 min???
Nothing seems to help here:
- browser refresh
- logout and re-login
- permanently delete page from Notion Trash
It seems that the removed page in Notion stays for (almost) ever in cache somewhere. This makes this Softr-Notion very unserfriendly.
Please don’t advise to migrate to Softr databases. I’m using SoftrDatabases for another project. And indeed, none of these probleems are reported there. But migrating to Softr Databases for this project is no option. In my opinion, the existance of Softr Databases should not be a reason for not creating a responsive Softr-Notion integration.
Technically, I think we need a much smaller cache invalidation time, a webhook to be able trigger the synch. manually, …
Can anyone help?
I would debug the deleted-page case separately from normal Notion sync latency.
The quick test is to stop deleting the Notion page for one sample record and instead remove it from Softr with a simple boolean/status filter like “Visible in portal = yes”. If Softr drops it quickly when the filter changes but keeps it cached after the page is deleted or moved to trash, you have a reliable workaround and a clean Softr bug report: deleted Notion pages are not invalidating the list-block cache on the same schedule as property changes.
I would also test one minimal list block with no relations, rollups, or complex filters. That tells you whether the slow path is deleted-record invalidation specifically or a heavier Notion query/view issue.
TinyOps Studio can turn this into a short reproducible test plan, workaround, and client handoff note if useful: Softr Client Handoff Checklist - TinyOps Studio
Thx for your response.
Indeed, filtering on property values is a reasonable workaround (which we are using already), since editing property values indeed synchs quicker (see use case 1).
Unfortunately I cannot a simple publish boolean property, since I need to use record filters in Any-modus.
That makes sense. I would not add another top-level Softr OR filter.
A cleaner workaround is to move the OR logic into Notion. Add a formula property such as PortalVisible that evaluates the existing Any conditions and also requires an Archived or status property to be false. Softr then filters on one field: PortalVisible = true. Removing a record from the portal becomes a property update instead of deleting the page, so it should follow the faster sync path you have already measured.
I would test it on one cloned record before changing production:
- one existing condition matches → visible
- no conditions match → hidden
- Archived is true while another condition matches → hidden
- Archived is false again → visible
If you share the property names and the current Any conditions (no client data), I can sketch the exact Notion formula here. If the filter structure is client-sensitive, TinyOps can map and test it privately as a fixed-scope $149 audit; the private order path is in the link from my previous reply.
