The plumbing this replaces
Every company that runs on shared sheets has built the same set of workarounds, usually without deciding to.
| The workaround | Why it existed |
|---|---|
| Exporting the sheet weekly and uploading it somewhere | The numbers had to reach a report, and the report could not read the sheet |
| Pasting in employee names, product codes, unit names | The sheet had no way to refer to the real ones |
| Copying rows into a ticket to get them approved | Approval lived in a different system |
| A script that pulls the sheet into a database at night | Something downstream needed the data as data |
| A person who remembers how all of the above is wired | None of it was ever designed as a whole |
None of that was anybody's mistake. A file cannot be part of a system; it can only be moved into one, repeatedly, by hand or by something somebody wrote.
What happens instead
What is typed becomes queryable data. Rows are kept as data the platform can read, so the sheet can be reported on, joined and charted like anything else - no export, no nightly job, no second copy that drifts. Analytics is the same distance from a sheet as it is from a database table.
A process can read the sheet, and act on it. Automations and business processes read the same rows. A plan entered in a grid can start approvals, raise tasks, notify people, or hold the line items an approval is about - without those rows being copied anywhere first.
The org structure is a column type, not a habit. A cell holding an employee, a position, a unit or a legal entity refers to the real one in the org structure. It does not need maintaining when somebody moves, and a route can resolve responsibility from it.
Dictionaries stop being copy-paste. A column bound to a shared dictionary offers the values the company actually uses, and stays right when that list changes.
A dataset can be pulled in, and what you build stays connected. Start a sheet from a dataset or a model when the work begins with existing data instead of a blank grid.
A workbook ships as part of an application. It is declared alongside the data model, the processes and the pages, versioned with them, and installed with them - so "the planning workbook" is a defined object with a history, not a file that was once attached to an email. See Apps.
Discussion sits on the numbers. Comments anchor to a cell or a range, so the argument about one figure is attached to that figure and stays with it.
The grid is one of the platform's surfaces
Every ERP and every CRM has a spreadsheet next to it. Not inside it - next to it. Data is exported to be worked on, and the result is typed back in, because the system's screens were designed for entering records one at a time and the work in front of somebody is a hundred rows they need to see at once.
That gap is where a surprising share of a company's real work lives, and it is invisible to the system that thinks it is the system of record.
Here the grid is one of the platform's surfaces, with the same status as a dashboard, a form or a board. So the scenarios below are not clever integrations; they are what falls out of a spreadsheet being a first-class place for things to happen.
Where this changes what is possible
Beyond less plumbing, some things become reasonable that were not worth attempting before.
- A planning cycle that is actually a process. Department heads enter their numbers in a grid, the submission starts an approval route, the approved rows land in the model everyone reports on, and the dashboard is looking at the same rows the plan was typed into.
- Reference data maintained by the people who know it. A price list, a target, a rate table - edited in a grid because that is what suits the work, read by the platform as a source because that is what suits everything else.
- The system of record for the thing nobody built a system for. Every company has a handful: the equipment register, the contractor list, the exceptions log. They start in a grid because the grid is instant, and here they can stay there without staying disconnected.
- A form replaced by a grid where a grid is honestly better. Filling twenty rows through a one-record-at-a-time form is unpleasant, and everyone knows it. Twenty rows in a grid, typed the way people type, entering the same system the form would have.
Next
Under the hood - how simultaneous editing stays consistent, how rows become readable data, and why a shared formula needs a stricter sandbox than a private one.
And Built with AI if the model you are about to build by hand is one you could describe instead.