# Connected to the rest

> The round-trips a spreadsheet usually needs - export, upload, paste, remind somebody - stop existing when the sheet is already inside the system the data was going to

Source: https://aipril.dev/docs/spreadsheets/connected

## 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](https://aipril.dev/docs/analytics.md) 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](https://aipril.dev/docs/processes.md) 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](https://aipril.dev/docs/ai-organisation/people.md). 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](https://aipril.dev/docs/apps.md).

**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](https://aipril.dev/docs/spreadsheets/under-the-hood.md) - 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](https://aipril.dev/docs/spreadsheets/ai.md) if the model you are about to build by hand is one you
could describe instead.