Drive & datasheet

In one line. The platform’s two storage substrates: Drive (raw files in folders) and Datasheet (structured data as a flat SQL table). You’ll be able to. Upload and organise project files in Drive, create a Datasheet from a database/spreadsheet/API or from a View, read its data and system columns, and understand how an agent queries it with SQL. Where this lives. Studio ▸ Data Model ▸ Drive and Studio ▸ Data Model ▸ Data (Datasheet).

Why it matters

A Collection is the typed home for documents — it has a schema, a lifecycle, agents. But two kinds of data don’t fit that mould. Sometimes you just need a place to put raw files (a pile of PDFs to ingest later, a reference spreadsheet, an export). That’s Drive. And sometimes you need structured rows you can query with SQL — a lookup table of vendor codes, a feed of rows from your ERP, or a flattened copy of what your agents extracted. That’s a Datasheet.

Think of them as the substrate beneath Collections: Drive is the file system, Datasheet is the database table. Both live under Studio ▸ Data Model, alongside Collections — they are inputs to and outputs from collections, not collections themselves.

Drive — project file storage

Purpose. Drive is a folder tree + file browser over your project’s Botminds Storage. You upload raw files here, organise them in folders, and — most importantly — a Drive connector can pull from it during ingestion, so Drive is a common staging area for documents on their way into a Collection.

Where this lives. Studio ▸ Data Model ▸ Drive.

Layout

Left “Storage” rail — a Home button plus a recursive, indented folder tree. Carets expand/collapse folders; click a folder to open it in the right pane.
Right pane — a breadcrumb trail (Home ▸ … ▸ current folder), a Total file count, a Search by name box, the toolbar (below), and the file table.
File table — columns Name (with a type icon), Date, Size, plus per-row Download and Copy Path actions. Folders sort first. Single-click selects a row (checkbox); double-click opens a folder. Long lists page with Load More.
Empty state — “There is no files and folder available in this Folder” with an Add Documents button.

What every control does

Control	What it does	Notes
Search by name	Filters the current view by filename	Name match, current folder
Refresh	Re-reads the current folder from storage	Use after an upload or external change
Delete selected	Deletes the checked files/folders	Destructive — see Watch out below
Upload Progress	Opens the in-flight upload tracker	For large/many-file uploads
Copy Path	Copies the storage path of the selection (toolbar) or of one file (per row)	Handy for wiring a connector to a folder
Add Folder	Creates a new sub-folder in the current folder	Name it, confirm
Add Documents	Uploads files into the current folder	The primary upload action

Walkthrough — stage files for ingestion

Open Studio ▸ Data Model ▸ Drive.
In the Storage rail, click Home, then Add Folder and name it (e.g. Invoices).
Double-click into the new folder. Click Add Documents and select your PDFs.
Watch the Upload Progress tracker; when it finishes, click Refresh to see the rows.
Click Copy Path on the folder — you now have the path to point a Drive connector at when you set up ingestion.

How Drive relates to ingestion

Drive on its own just stores files — nothing processes them. To get files from Drive into a Collection, you create a Drive connector and a Source/Job scoped to a Drive folder; the job fetches the files and runs them through the collection’s ingestion XFlow. Drive is the staging area; the connector is the conveyor belt. Connectors, sources, and jobs are covered in Ingestion & connectors.

Tip. Keep an _exports or _staging folder convention so it is obvious which folders a connector is watching versus which are just human drop-zones.

Watch out. Delete selected removes files from storage. If a connector or a document already references a file, deleting it from Drive can leave the downstream record orphaned. Delete from Drive only files that haven’t been ingested, or that you’re sure nothing points at.

Datasheet (“Data”) — the structured-data layer

Purpose. A Datasheet is a flat SQL table — the platform’s structured-data layer. Each Datasheet is materialised as a real backing table that an agent can query directly with SQL. You use a Datasheet when you need rows and columns rather than documents: a lookup table, an external feed, or a flattened copy of extracted data.

A Datasheet gets its rows in one of two ways:

Sourced from an external source connection — a database, a spreadsheet, or an API response is pulled in and written to the table.
Materialised from a View — a saved, filtered slice of a Collection’s documents (its extracted labels become columns) is flattened into the table. Views are covered in Shaping the experience.

Where this lives. Studio ▸ Data Model ▸ Data.

Layout

┌──────────────────────────────────────────────────────────────────────────────────┐
│ [ Datasheets | Sources ]  │  Vendor Master                                         │
│ ─────────────── refresh   │  ─────────────────────────────────────────────────────│
│  Vendor Master        ◀── │  [ Data | Details | Run Info ]                         │
│  Q2 Invoices (View)  ok   │  ──────                                                 │
│  ERP Feed          warn   │  [ Filter ]  "vendor_status" = 'active'  [ Apply Query ]│
│                           │  ┌───────────────────────────────────────────────────┐ │
│                           │  │ vendor_code │ name      │ _BM_STATUS │ _BM_RUN_ID   │ │
│                           │  │ ACME-01     │ Acme Inc  │ OK         │ 9f3…         │ │
│                           │  │ GLBX-04     │ Globex    │ OK         │ 9f3…         │ │
│                           │  └───────────────────────────────────────────────────┘ │
│  ─────────────────────    │                                                         │
│  [ + Datasheet ]          │                                                         │
└──────────────────────────────────────────────────────────────────────────────────┘

Left rail — two tabs. Datasheets lists your datasheets (each shows name + description and a status icon/tooltip), with a Refresh button at the top and a + Datasheet button in the footer. Sources lists the source connections (the DB/spreadsheet/API bindings that feed datasheets); selecting one opens its view/edit/delete details.
Right pane (a Datasheet selected) — three sub-tabs. Data shows the rows in a data table over the backing table; a Filter toggle reveals a SQL query box where you type a condition like "column" = 'value' and click Apply Query. Details is the datasheet’s editable metadata. Run Info is execution history, with an Exclude Empty Runs checkbox to hide runs that produced no rows.
Empty states — “No Datasheet found in the project”, “No sources found in the project”, and “You haven’t selected datasheet…” (nothing selected yet).

What every control does

Control	What it does	Notes
Datasheets tab	Lists datasheets; select one to load the right pane	Status icon shows last-run health
Sources tab	Lists source connections (DB / spreadsheet / API)	Where a datasheet’s data comes from
+ Datasheet	Opens the add-datasheet flow	See walkthrough below
Filter toggle	Reveals the SQL query box on the Data sub-tab	Quoted-column syntax: `"col" = 'value'`
Run Info sub-tab	Shows run history	Exclude Empty Runs hides no-row runs

The system columns

Every Datasheet carries three platform-managed system columns alongside your data columns. You don’t create or edit them — the platform stamps them so it can track where each row came from:

Column	Meaning
`_BM_STATUS`	The row’s processing status (e.g. OK / pending / error)
`_BM_RUN_ID`	Which materialisation/refresh run produced the row
`_BM_JOB_ID`	Which ingestion job the row is associated with

Under the hood. The backing table is named like DATA_SHEET_{id}_{guid}. When you filter on the Data tab you are issuing SQL against that table; the same table is what an agent’s SQL tool reads. The system columns let the platform reconcile rows across re-runs without duplicating them.

Walkthrough — add a Datasheet from a source connection

Open Studio ▸ Data Model ▸ Data.
Click + Datasheet (footer of the left rail) to open the add-datasheet dialog.
Give the datasheet a name and description.
Choose its source: either pick/create a source connection (a database, spreadsheet, or API binding — the same connections listed under the Sources tab), or point it at an existing View to materialise that View’s columns into the table.
Confirm. The datasheet appears in the list with a status icon; open it and check the Data tab for rows and Run Info for the first run.
To add a source connection on its own, switch to the Sources tab and create one there — then it is available to bind from any datasheet.

Tip. Filter on the Data tab to sanity-check your data before you wire an agent to it: if "vendor_status" = 'active' returns the rows you expect, the agent’s SQL tool will too.

How agents query a Datasheet

The whole point of a Datasheet is that an agent can read it with SQL. When you give an agent a SQL tool (a SQL toolkit pointed at a datasheet), the agent writes queries against the backing table to answer questions or look values up mid-task — “what’s the approved credit limit for vendor ACME-01?” becomes a SELECT the agent runs itself.

This is how structured chat works too: an agent backed by a datasheet answers questions by querying rows rather than retrieving document chunks. You’ll wire the SQL tool in Tools & functions, and see structured (data-backed) chat in Chat & search.

Under the hood. An agent’s capability is data-driven by its config: bind a datasheet_id and it becomes a SQL agent; bind a view_id and it becomes a search agent; bind neither and it’s a general agent. The datasheet binding is literally what turns on the SQL tool.

When to use Drive vs Datasheet vs a Collection

These three look adjacent in the menu but solve different problems. Pick by the shape of your data and what you need to do with it:

Need	Use	Why
Store/organise raw files (PDFs, images, exports)	Drive	A file system. No schema, no querying — just files in folders.
Structured rows you’ll query with SQL (lookups, feeds, flattened extracts)	Datasheet	A flat SQL table an agent can `SELECT` from. No documents, no lifecycle.
Documents you extract from, review, and decide on — or a corpus you answer over	Collection	The full typed home: schema, lifecycle, agents, surfaces. The hero object.

Rules of thumb:

If a human or a connector needs to drop files somewhere — Drive.
If an agent needs to look something up in tabular data — Datasheet.
If you need per-record extraction, review, or Q&A — Collection.
Data often flows Drive → (connector) → Collection → (View) → Datasheet: files land in Drive, a connector ingests them into a Collection, a View flattens the extracted fields, and a Datasheet materialises that View for an agent to query. It can also flow back: a Datasheet connector (Ingestion & connectors) re-ingests a datasheet’s rows as documents, and picks up new/edited rows automatically.

Try it yourself

In Drive, create a folder staging, upload two PDFs into it, then Copy Path on the folder. You’ve just prepared a target for a Drive connector (Ingestion & connectors).
In Data, click + Datasheet and create one — either materialise it from a View you already have, or bind a small spreadsheet as a source connection.
Open the new datasheet’s Data tab, toggle Filter, and run a query like "_BM_STATUS" = 'OK'. Note how the three _BM_* system columns appear next to your own columns.
Open Run Info and tick Exclude Empty Runs — confirm you only see runs that produced rows.

If you got rows back from your filter, that same table is now ready for an agent’s SQL tool.

Recap

Drive (Data Model ▸ Drive) is project file storage: a folder tree + file browser with upload, new-folder, move/delete, download, and copy-path actions. A Drive connector can pull files from it into a Collection during ingestion.
Datasheet (Data Model ▸ Data) is a flat SQL table — the structured-data layer. The left rail has Datasheets and Sources tabs; a selected datasheet shows Data / Details / Run Info sub-tabs, with a Filter → SQL query → Apply Query box on Data.
A Datasheet is either sourced from a DB/spreadsheet/API connection or materialised from a View, and always carries the system columns _BM_STATUS / _BM_RUN_ID / _BM_JOB_ID.
Agents read a Datasheet by SQL via a SQL tool — the foundation of structured chat.
Choose Drive for raw files, Datasheet for queryable rows, Collection for documents you process or answer over.

Where to go next

Your first agent — build the worker that will use this data.
Tools & functions — wire a SQL tool to a Datasheet.
Ingestion & connectors — point a Drive connector at a Drive folder.
Glossary — Drive, Datasheet, View definitions.