Most importers take one tab. A spreadsheet that a business actually runs on is a book: a summary at the front, a page per thing, and a calculator somewhere near the back. This is what happens to each of them.
Nine tabs. Not a made-up example — a real buyer's guide someone keeps by hand:
| Tab | What it is | What happens to it |
|---|---|---|
| Overview | A table, 29 rows, 14 columns | Imported as records |
| Anker, Bluetti, Ecoflow, Jackery, Pecron, Point Zero, Renogy | Seven tabs, each one product written sideways — name across the top, ~50 attributes down the side | Read as records too, and merged into one collection: 30 products, 135 fields |
| Capability Calculator | Running totals and a #DIV/0! | Left alone |
The seven brand tabs are the point. They are where the detail lives, and they are the reason "just import the first tab" is the wrong answer: the tabs are what make things related to one another.
When a thing has fifty attributes, nobody keeps it as a row — you would be scrolling right forever. People turn it on its side: the name in the top cell, the attributes running down column A, the values in column B. Then they copy that block for the next product, or give it its own tab.
An importer that only knows "columns are fields, rows are records" sees that and produces two records with fifty columns of nonsense. Reading it correctly means noticing the shape first, and then noticing that seven tabs share it.
Nobody fills in seven tabs consistently. In this one:
1056 under "Capacity (Wh)". Another writes 2048Wh.28 under "Weight (lbs)". Another writes 61.9 lbs.1800 on one tab and 1100/700 on another.So a column's type has to be decided by every tab that will share it, not by the first one read. Where a column is a number on one tab and prose on another it becomes text, because that is the only shape that holds both. Getting this wrong is not a cosmetic problem: infer the options for a dropdown from one tab and the next tab's own values get refused as invalid.
#DIV/0! is left alone. Importing a spreadsheet's arithmetic error
into a database is worse than not importing it.2048Wh under "Capacity (Wh)" is read as 2048, because the column
declared the unit. 61.9 kg under "Weight (lbs)" is refused —
storing 61.9 where you meant 136 is the kind of wrong you never see again.03/04/2026 stops and asks day-first or month-first.And a refusal leaves your app exactly as it was — not half a collection with the fields added and the records missing.
It moves records. It does not convert an application. Formulas do not become live calculations; they arrive as the values they had. There is no scripting language here at all, so anything whose worth is its macros is a poor fit and a custom build will beat us — the whole automation catalogue is set out on the Access page. CSV import is one file at a time; the whole-book reading is the Google Sheets path, because a link can see the other tabs and an uploaded file cannot.
Google's own AppSheet states the limit plainly in its documentation: "Up to five worksheets from the Google Sheet will be imported into the AppSheet database."1 The sheet above has nine, and seven of them belong in one collection rather than seven.
That is a real difference and also a narrow one. AppSheet is a mature product with a mobile app, and we are not: Bionic Forms is pre-launch, has had five signups who are not us, none of whom has typed a record, nobody paying, and there is no iOS or Android app. If you want the honest version of where we are, it is on /access and in llms.txt.
Rather not assemble it yourself? Tell us what your current system does and we will build a working version and show you. No fee and no card — what we build fits the free plan.