Plexara
Spreadsheets as Tables
From file to table
From spreadsheet to SQL, without a load step
A spreadsheet becomes useful when it is joined against the data you already have. Rebates against sales. Lease costs against revenue. A target list against the customer table. Getting the file somewhere joinable used to mean a request to data engineering and a loader somebody has to own, so for a file needed once, it rarely happened at all.
Registering skips all of that. Plexara reads the file, takes column names from its header row, and creates a table that reads the file exactly where it is stored. The table lives in a scratch schema set aside for working data, beside your warehouse in the same SQL surface, ready for your assistant and your analysts alike.
It matters just as much for the files your assistant creates. An export it saves, or a dataset it assembles from API calls, is already stored in Plexara; registering makes it joinable, so the work an agent did yesterday becomes a table the whole team queries today.
Nothing is copied
The table reads the file where it already sits
One step
A button in the portal, or a single call by your assistant
Any size
300 rows or 300,000 query exactly the same way
Both directions
Files people upload, and files your assistant builds and saves
How it works
Upload, register, join
Files already reach Plexara as uploads and saved assets. Registering is the one new step, and it turns any of them into a table.
- 1
A file lands
Someone uploads a CSV to the resource library, or your assistant saves one it built as an asset. Either way the file gets versions, an owner, and a place the whole team can find it.
- 2
Register it
Pick a connection and, if you like, a name. Plexara reads the header, creates the table over the file where it sits, and answers with the columns. Your assistant does the same thing with a single call.
- 3
Join it by name
The table sits beside your warehouse in the same SQL. Columns arrive as text, so a join to a numeric key uses a cast, and the registration answer includes a sample statement showing exactly that.
Lifecycle
How the table tracks the file
A table over a living file raises two questions: is it current, and can the file be read the way it is stored? The ledger below covers every state, and once a file is registered, its search result carries the table name and a sample join.
The file
The table
Where you see it
The file
Overwritten in place
The table
The next query reads the new content. A recurring vendor drop stays current with no re-registration.
Where you see it
No flag; the table was never behind.
The file
Gains a version through an edit or revision
The table
Keeps serving the version it was registered against. Registering again moves it forward in one step.
Where you see it
A stale flag on the portal panel, the file's search hit, and the assistant's own listing.
The file
Cannot be read as stored
The table
No table is created and nothing is recorded. Line breaks inside cells, old Mac line endings, and wrong encodings would otherwise become rows made of fragments.
Where you see it
The refusal names the specific problem and offers a correction where one can be made mechanically.
The file
Corrected by that one control
The table
The repaired content is written as a new version of the file, and the table is registered over it.
Where you see it
The version history says what changed and why; the original upload stays as the version before.
The file
Unregistered
The table
The table is dropped. The file is untouched, byte for byte.
Where you see it
The panel no longer lists it; the audit record of the registration remains.
The file
Deleted
The table
Every table registered over it is dropped, whoever registered them.
Where you see it
Nothing keeps serving data whose source is gone.
Governance
A shared workspace with clear ownership
The scratch schema is shared on purpose: a table one analyst registers is a table the whole team can query. What keeps that safe is the same identity, authority, and audit model as every other Plexara surface, stated here as the four rules the platform enforces.
01
Every registration is audited
Who registered what, on which connection, and the statement that ran, recorded for every registration and unregistration, including the attempts that were refused.
02
Names carry the persona
Table names are prefixed with the registering persona, so a shared workspace stays legible: anyone reading the schema can see whose working table they are looking at.
03
Registering takes real authority
A registered table is readable by everyone granted the connection, so registering a file requires the authority to change it, not merely to read it. Nobody widens an audience by accident.
04
Names are claimed, not overwritten
The person who registered a table is the one who can drop it, along with administrators. Names are claimed on registration, and a name someone else holds is refused rather than overwritten.
Where agent-built files come from
API Gateway
Your assistant can pull from any connected API, save the result as a file, and register it. See what it can reach.