Files and data in Connect
Files and data are two surfaces over records that already exist. Files go through one service both audiences share, storing versions rather than overwriting. The Data grid is a spreadsheet view of 13 record sheets, and every edit it makes goes through the service that owns the record. Neither surface holds a private copy of anything.
One file service, two audiences#
Files attach by button, drop or paste and land in file_workspace, which sits over the media_assets table. That table was already scoped to a workspace and already under row-level security, so files needed no new table and inherited isolation rather than re-implementing it. An operator's document and a customer's take the same path through the same code; what differs is which workspace the row belongs to.
Reading one means extracting from it with the standard library, not shipping it to a third party for interpretation. Images, PDFs, Word documents, spreadsheets, presentations, delimited text and plain text each have a reader. File formats Connect reads lists all of them with what comes out of each.
A change to a file is always a new version, carrying provenance — who or what produced it, and from which version. There is no in-place edit, so a bad modification is recoverable by pointing at the previous version rather than reconstructing it.
The grid is a view, not a second database#
#/data is an Excel-like grid over 13 sheets: companies, people, leads, prospects, follow-ups, deals, conversations, calls, cases, onboarding, knowledge, files and memory. It virtualises rows, and it sorts, filters, groups, freezes, resizes and reorders columns, saves views, edits inline, acts in bulk, finds duplicates, imports and exports CSV.
The rule underneath all of that is one sentence: every change goes through the service that owns the record. An inline edit to a person in the grid calls the same code a person's screen calls, so the same validation, the same audit entry and the same downstream effects happen. A grid that wrote rows directly would be a second CRM with its own bugs, and would quietly diverge from the product around it.
| Files | The Data grid | |
|---|---|---|
| Where it lives | The Files section, and inside an Assistant tab | #/data |
| What it holds | Documents, images and spreadsheets you supply or Connect produces | The workspace's own records, across 13 sheets |
| How a change is made | A new version, always | An edit through the owning service |
| What it never does | Overwrite the previous bytes | Write to a table on its own |
Where to go next#
- Putting something in: adding a file, then validating a file for what is refused and why.
- Getting something out: reading text out of a document and reading tables out of a file.
- Working with the grid: the Data grid, saved views and editing in the grid.
- Moving data in bulk: importing and exporting, and a CSV export that looks escaped when the neutralising of formulas surprises you.
The rule that governs both#
The canonical record owns the truth. A document is evidence about a record and a grid cell is a view of one, but neither is the record itself. When an attachment says one thing and the record says another, the record is what the rest of Connect acts on — a call brief, a draft reply, a follow-up all read records, not attachments.
That is worth internalising before importing a spreadsheet of customers. The import creates and updates records; the spreadsheet is not thereafter the source. Editing the original file changes nothing, and re-importing it over later work is how a workspace loses a week of updates.
Everything in this section#
24 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| Adding a file | Three ways to add a file — button, drag-and-drop, paste — what happens the instant it lands, and the checks it must pass before anything reads it. |
| Answering from a file | Grounding an answer in an attachment instead of in a model's memory: how Connect quotes a file, what happens when the file does not say, and what a citation means. |
| Bulk selection and actions | Selecting many rows on the Data screen and acting on them at once: how a bulk change is applied row by row, and what a partial result means. |
| Changing a file | Why changing a file in Connect always produces a new version instead of overwriting it, and exactly what the version you started from keeps. |
| Columns, order and visibility | Arranging a sheet on the Data screen: resizing, reordering, hiding and showing columns, what a hidden column still does, and how to keep an arrangement. |
| Creating a file | How Connect produces a file: what it can be built from, which formats it will and will not write, and where the finished document lands. |
| Duplicates in the grid | How the Data screen surfaces records that look like the same person or company, what merging actually does, and why it is never done automatically. |
| Editing in the grid | Changing a value in a cell on the Data screen: which fields accept an edit, which service actually performs it, and why some edits are refused. |
| File formats Connect reads | Every file format Connect reads, what is actually extracted from each one, and the limits worth knowing before you rely on an answer drawn from it. |
| File versions | The version chain a file keeps in Connect: what one version records, what provenance means here, and how the chain relates to the audit trail. |
| Filtering and searching a sheet | Narrowing a sheet on the Data screen: how filters on several columns combine, how search differs from a filter, and why a typed wildcard is just a character. |
| Importing and exporting | Getting records into and out of the Data screen: how an import is validated row by row, and why an exported CSV escapes cells that begin with an equals sign. |
| Linking a file to a record | Attaching a file to a company, a deal, a case or a conversation: what the link changes, what it does not, and where the file actually lives. |
| Parsing a file safely | Three refusals that keep document handling safe: external entity declarations, archives that expand out of proportion, and formulas neutralised on the way out. |
| Previewing a file | What a file preview shows and what it deliberately does not: stored bytes for an image, extracted content for a document, and nothing fetched from the network. |
| Reading tables out of a file | How XLSX and delimited files are read into rows and columns, what survives the trip, and the four things that are reliably lost on the way. |
| Reading text out of a document | How words come out of a PDF, a DOCX, a PPTX or a plain file, what reading order means in practice, and what happens when a document has no text layer at all. |
| Saved views | What a saved view on the Data screen keeps, why it grants nobody any access they did not have, and how to get a sheet back to how it arrived. |
| Sorting, grouping and freezing | Ordering rows, gathering them under a shared value and pinning the columns you read against — and what happens when you use all three at once. |
| The Data grid | The Data screen: an Excel-like grid over thirteen record sheets, what each sheet holds, and why it is a view of Connect rather than a second database. |
| The grid on a small screen | What the Data screen becomes on a phone: the controls that survive the loss of width, the ones that are dropped, and why dropping them is the right answer. |
| The record of a file | The trail a file leaves in Connect: who added it, who changed it, what was refused, and what was produced from it — and what the trail deliberately does not hold. |
| Understanding an image | How Connect reads a photo or a screenshot: the image formats it accepts, what the model is actually shown, and the questions a picture cannot answer. |
| Validating a file | What Connect checks about a file before any parser touches it: the type check against the bytes, and the two structural attacks the checks exist to stop. |
Questions#
Is there a separate file store for the operator and for customers?
No. One service, one table, two workspaces. Isolation comes from the workspace stamp on the row and from row-level security, not from keeping separate code — which is why a fix to file handling reaches both audiences at once.
Can I use the grid as a spreadsheet for arbitrary data?
No. Its sheets are the workspace's own record types, and a column exists because a record has that field. For arbitrary tabular data, upload the spreadsheet and ask the Assistant about it instead.
Does deleting a file remove it from the records it was linked to?
The link goes with it, but the records themselves are untouched. Records do not depend on their attachments, which is the practical consequence of the canonical record owning the truth.