Drive & datasheets

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

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, a datasheet is the database table.

Both live in the Data pillar alongside Collections, Ingestion, Input Form, Views and Export. The pane is one flat list, in flow order:

Collections · Ingestion · Input Form · Drive · Datasheets · Views · Export

Drive and Datasheets 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 file 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 ▸ 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 ▸ 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 job scoped to a Drive folder; the job fetches the files and runs them into the collection. Drive is the staging area; the connector is the conveyor belt. Connectors, jobs and runs are covered in Ingestion & connectors — the entry directly above Drive in the Data pane.

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.

Datasheets — the structured-data layer

Purpose. A datasheet is a flat SQL table — the platform’s structured-data layer. An agent can query it 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 three ways:

Entered by hand — type or paste rows straight into the grid. The simplest option, and often all a lookup table needs.
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 live at Studio ▸ Data ▸ Views — under Data, not under Experience, which is where most people look first.

Where this lives. Studio ▸ Data ▸ Datasheets.

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      │ vendor_status │ region  │ │
│                           │  │ ACME-01     │ Acme Inc  │ active        │ EMEA    │ │
│                           │  │ GLBX-04     │ Globex    │ active        │ AMER    │ │
│                           │  └───────────────────────────────────────────────────┘ │
│  ─────────────────────    │                                                         │
│  [ + 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; 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 sourced 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

Filtering the Data tab

Toggle Filter on the Data tab and a query box appears. The placeholder shows the syntax: quote the column, quote the value — "column_name" = 'value' — then click Apply Query. Clear the box to go back to the full table.

The columns you see are the columns you defined (or the ones your source or View supplied). The platform keeps its own bookkeeping about where each row came from and which refresh produced it — that is what lets a re-run reconcile rows instead of duplicating them — and it keeps that bookkeeping out of your way: it is not in the grid, and it is not part of what an agent queries.

Filtering here runs your condition against the same rows an agent’s SQL tool reads, so what you see is what the agent will see.

Walkthrough — add a datasheet

Open Studio ▸ Data ▸ Datasheets.
Click + Datasheet (footer of the left rail) to open the add-datasheet dialog.
Give the datasheet a name and description.
Choose where its rows come from: fill it by hand, pick or 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 pointed at a datasheet, the agent writes queries against the 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 experience.

Attach a datasheet to an agent and it can query rows; attach a view and it searches documents. What you attach is what it can reach.

When to use Drive vs a datasheet vs a Collection

These three sit next to each other in the Data pillar 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 — a datasheet.
If you need per-record extraction, review, or Q&A — 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 Datasheets, click + Datasheet and create one — enter a handful of rows by hand, 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 against one of your own columns — "vendor_status" = 'active' — then click Apply Query. Clear the box to bring the whole table back.
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

The Data pillar is one flat list, in flow order: Collections, Ingestion, Input Form, Drive, Datasheets, Views, Export.
Drive (Studio ▸ Data ▸ Drive) is project file storage: a folder tree + file browser with upload, new-folder, delete, download, and copy-path actions. A Drive connector can pull files from it into a Collection during ingestion.
Datasheets (Studio ▸ Data ▸ Datasheets) are flat SQL tables — 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’s rows are entered by hand, sourced from a DB/spreadsheet/API connection, or materialised from a View (Studio ▸ Data ▸ Views — under Data, not Experience).
Agents read a datasheet by SQL via a SQL tool — the foundation of structured chat.
Choose Drive for raw files, a datasheet for queryable rows, a 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.