Most content folders hold documents to be searched. A Spreadsheets folder is different: it holds spreadsheets and turns each of their tabs into database-style tools, so agents can list, look up, insert, update, and delete rows without ever thinking about cells, ranges, or row numbers.
It is the fastest way to give a workflow a table to work against. It is also, in the long run, the wrong place to keep data that matters — the end of this article explains why, and what to do instead.
Creating one
Add a content folder and choose the Spreadsheets type rather than General Documents. A Spreadsheets folder is for structured data access rather than search: the spreadsheets you connect to it become tools, not indexed documents.
Then add spreadsheets to it, from Google Drive, from OneDrive or SharePoint, or by uploading an .xlsx or .csv file.
Two things about adding are worth knowing:
The folder only accepts spreadsheets. Add a PDF or a Word document and it is refused straight away, with the rejected file named — you do not discover the problem later when a tool is missing. Adding ten files of which two are not spreadsheets adds the eight and tells you about the two.
Each entry is one registered spreadsheet, not an import of its rows. Adding a workbook makes that workbook available to the folder's tools; it does not copy its contents into the thunk. If you want the rows as work items instead, use the import described in Working with Spreadsheets.
What you get
For every tab of every spreadsheet in the folder, the platform reads the header row and generates a matching set of tools, named after the data they hold. A workbook of orders produces tools that read like orders_list, order_lookup, order_insert, order_update, and order_delete. A multi-tab workbook produces one set per tab.
Tool | What it does |
List | Returns the rows of the tab |
Look up | Finds rows by a column value |
Insert | Adds a row, supplying values by column name |
Update | Finds a row by a column value and changes named fields |
Delete | Removes a matching row |
Because the tools are built from the actual header row, the agent works in your vocabulary — Customer, Invoice Total, Due Date — and cannot address a column that does not exist.
These tools appear on the folder's Tools tab, alongside the folder's content, and they are switched on for the thunk automatically. You can turn any of them off, and steps can opt in or out of them individually like any other tool.
A few practical rules:
A tab with no header row produces no tools. Give every tab a header row.
The tool set is rebuilt when spreadsheets are added or removed, or when you re-index the folder. If you change a tab's columns in the spreadsheet itself, re-index the folder so the tools match.
Read-only is a switch on the folder. With it on, agents can look up and list rows but cannot add, edit, or delete them. Turning it on (or off) also takes effect on a re-index.
Uploaded
.xlsxand.csvfiles are stored copies, so they always get list and lookup tools only. Keep the spreadsheet in Google Drive or OneDrive if agents need to write to it.
Where this stops being a good idea
Treating a spreadsheet as a database is genuinely useful, and the platform supports it on purpose. But be clear-eyed about what you are relying on. A spreadsheet is not a sound store for enterprise data, and the reasons are not about this platform — they are properties of spreadsheets.
There are no transactions. A change that spans several rows can half-complete. A real database either does all of it or none of it; a spreadsheet has no such guarantee.
Concurrent editing is unmanaged. A colleague with the file open in Excel, an agent updating a row, and a scheduled step appending results are three writers with no coordination between them. Somebody's change gets lost, and nothing announces it.
There is no schema to enforce. Rename a column, insert a heading row above the headers, or paste text into a numeric column, and nothing objects. The tools are rebuilt from whatever the header row now says, so a well-meant tidy-up can quietly change what your agents can do.
There are no constraints or relationships. Nothing prevents duplicate keys, orphaned references, or a status value that is not one of the allowed statuses.
Access is all-or-nothing. Anyone who can open the file can read every row. There is no per-row or per-column permission.
It does not scale. Both size and request-rate limits arrive sooner than people expect, and performance degrades well before the hard limits.
The audit trail is weak. Version history tells you the file changed. It is poor evidence for who changed which field of which record, and why — which is exactly the question a regulator or an auditor asks.
The healthy pattern
Use a Spreadsheets folder to prototype. It removes an enormous amount of setup: you can have a working automation reading and writing real data within minutes, prove the workflow is right, and show it to the people who own the process.
Then, when the process is real, move the data:
Into the thunk, by importing the rows as work items. Work items give you per-item status, history, review, and the reliability machinery a spreadsheet has none of. This is the right move when the workflow is the system of record.
Into the business system that should own it, reached through a connection — a CRM, an ERP, a ticketing system, a database. This is the right move when another system is the system of record and the spreadsheet was only ever standing in for it.
The spreadsheet remains a perfectly good place to report results. It is a poor place to keep them.