Teams who built their operations inside Notion, love it for writing, and have watched one particular database grow into the thing the business actually runs on.
Pull Notion into RowFold tables you own — filter them, report on them, link them to everything else in the workspace.
And it stays current: importing again updates the same tables, adding new records and updating changed ones, so links from your other tables hold. Keep in sync does that for you hourly or daily.
What it doesn't do: There are no automation steps that write back to Notion. It has no say in what a booking page offers. An import only reads: nothing is written back to Notion, a record deleted there stays here, and a sync runs hourly at most rather than the moment something changes. Anything else you have read about Notion and RowFold, this page is the authority: it is generated from the connector's own code.
The step people miss is not in RowFold at all: a Notion integration can only see what has been explicitly shared with it, so a perfectly healthy connection shows an empty list until you go back into Notion and share the database.
You'll know it worked: The new table shows the same row count as the Notion database, and a date column sorts chronologically rather than alphabetically. If the row count is short, check whether the database was filtered by the view you were looking at in Notion.
Notion relations survive as data but not as relations, because the import handles one database at a time. Rebuilding the links properly is a ten-minute job that turns a pile of tables into something you can ask questions of.
You'll know it worked: Open a parent record and confirm the linked children are listed on it. An empty list for a parent you know has children means the matching text had a variant, which is the problem the relation exists to end.
A Notion property is a suggestion. A date column accepts text, a number accepts a dash, and nothing stops somebody typing “TBC” into the field every report depends on. The errors arrive months later, in a total that is quietly wrong.
Properties are mapped to real field types on the way in, so a date is a date and a number is a number. What cannot be parsed is visible immediately rather than in a figure nobody re-checks.
Rollups and relations work until they matter. They are per-view, they recompute lazily, and past a few thousand rows the page that is supposed to summarise the business becomes the page nobody opens because it takes eight seconds to paint.
A rollup is computed by the database, over every matching row, and it is the same number in a grid, a report and an export. Size is not a reason it stops being usable.
The database is inside a page, and the page is inside a workspace nobody can query. There is no way to ask one question of six related databases, so the answer is assembled by opening each one and reading.
Imported databases are ordinary tables. Link them for real, then ask across them, and keep the answer as a report rather than as a ritual.
Everything downstream is manual. A row reaching a state means somebody notices and does the next thing, and that process exists only in the head of whoever usually does it.
Rows are records, so they can trigger work: the chase, the notification, the status change, each in a run log you can read afterwards.
Because Notion grants access per page, and probably nothing has been shared with the integration yet. This catches almost everybody, because the connection itself succeeded and looks perfectly healthy. Open the database in Notion, use the page menu to add RowFold as a connection, and it appears. Sharing a parent page shares everything nested underneath it, which is usually the quickest fix.
No, and the import says so in its warnings rather than leaving you to notice. In Notion every database row is also a page, and teams often keep the real detail in that page body. Only the row and its properties are imported. If the body matters, it is worth deciding before you move whether that content belongs in a long-text field or should stay in Notion.
No. The connection reads and never writes, so nothing you do in RowFold changes a Notion page, and no automation can. That is a deliberate limit rather than an oversight: a two-way sync between a page-based tool and a row-based one has to resolve conflicts that have no correct answer, and getting it wrong silently damages the original.
Their current values come across where they are readable, but the formulas themselves do not. That is usually the right outcome, because they are being replaced by something stronger: a rollup here is computed by the database over every matching row rather than recalculated per view, so it does not slow down as the table grows and cannot differ between two screens.
For docs, wikis, meeting notes and anything you mainly write rather than query, no — Notion is better at those than a workspace builder will be. The case for moving is narrower and specific: the one database that quietly became the system the business runs on, where you now need types that hold, totals that are right, and questions asked across several tables at once.
There is no template to wait for. Type a sentence about what you run and RowFold assembles the tables, links, views and dashboard around it — then you change whatever does not fit.