Reference
Data
A dataset is a table the workspace owns: columns you name and give a type, and rows underneath them. It lives in your workspace rather than on one machine, so a teammate opens the same table you do, and an automation running tonight writes into the one you were reading this morning.
On this page
A table the workspace owns
A dataset is not a file on this machine. It belongs to the workspace, which is what makes it worth putting results in: a teammate opens the same table you have open, and the run that finishes at three in the morning writes into the one you were reading yesterday. Nothing has to be sent anywhere for that to be true.
Columns carry a type, and the type is what the grid honours: text and long text, number, checkbox, date and date-time, a URL, an email, a phone number, a select with coloured options, and tags. A row number and a created-at are computed rather than stored, so nothing you have to keep in step by hand.
Folders file datasets as the list grows, and a deleted one waits in Trash rather than going straight out.
A deleted dataset waits in Trash for thirty days and is then purged. Restore it from there, or empty the Trash yourself if you would rather not wait.
Columns and their types
Every column has a type, and the type is what the grid honours — the editor you get in a cell, how the column sorts, and what a value has to look like before it is accepted. Fourteen to choose from:
- Text
text - Long text
longText - Number
number - Stored as a real number, so sorting and ranges are numeric.
- Checkbox
checkbox - Date
date - Stored as YYYY-MM-DD.
- Date and time
datetime - Stored as a full UTC timestamp.
- URL
url - Email
email - Phone
phone - Status (one choice)
select - One coloured chip per row, from a list you define.
- Tags (many choices)
tags - Any number of chips per row, from a list you define.
- Created at
createdAt - Read from the row itself. Not editable.
- Row number
rowNumber - The row’s position on the page. Not editable.
- Automation parameter
parameter - Holds a reference like {{vars.email}} for automations to resolve.
Created at and Row number are computed rather than stored — they are read from the row itself, so there is nothing to keep in step by hand and nothing to edit.
Automation parameter is the one worth stopping on. A cell in that column holds a reference rather than a value — {{vars.email}}, exactly as an automation writes it — and the editor offers every parameter any automation in the workspace declares, so you are picking from a real list rather than typing a name and hoping. That is the difference between a dataset that reports what happened and a dataset that is a work list: a loadRowsstep reads the column back, and each row becomes the input to one pass of tomorrow's run.
How rows get in
Most rows arrive on their own. An automation running on a profile writes what it extracted straight into a dataset — a collection run is browser steps that end in save rows — and the save rows and load rows steps let one automation hand a table to the next: collect today, act on it tomorrow. The dataset list shows which automation fills each table, so a name in the Used by column tells you where the rows came from.
Import file takes CSV, JSON, TXT or XLSX, and either builds a dataset from the file's own headers or appends into one that already exists, merging any columns the file brought with it.
The import asks one question, and it is the useful one. New dataset starts empty and receives every row of the file, taking its columns from the file's own header row. Existing dataset appends into a table you already have, and any column the file brought that the table does not have merges in rather than being dropped.
The assistant is the fourth way, and often the fastest. Ask it for a table by name and it will read rows, filter and count them, add or correct them, or clear out duplicates. Anything bulk or destructive raises an approval card before it runs, so a request that turns out to mean four thousand rows asks you first.
Working the rows
Click a cell to edit it in place; each column type brings its own editor. Add rows and columns from the grid, filter and sort, tick rows to delete a batch, and freeze the first column when the table is wider than the window. Export gives you CSV or JSON of the whole thing.
Rows are paged straight from the database in insertion order, so what you see is the dataset itself rather than a page of it pretending to be sorted. A table of fifty thousand rows opens as fast as one of fifty.
Filtering and sorting happen on the server for the same reason, over the whole table rather than the page in front of you. A third press on a column header clears the sort and hands the table back to its stored order, which is why the order is worth having: it is the one arrangement that is always the truth about the dataset.
The ceilings, since they are the kind of number worth knowing before you build on them: a hundred thousand rows in a dataset, two hundred datasets in a workspace, sixty columns in a table, and 64 KiB in any single row.
The built-in destination
Your datasets are one of the destinations the database steps can write to. saveRows and loadRows point at a table of your own exactly as they point at Supabase, a Google Sheet or a CSV on disk — you pick Argus Datasets and name the table. There is no credential to store and nothing to connect, because it is already your workspace.
Two things it does that most of its neighbours cannot. It upserts by filter: give saveRows a column to match on and every row whose value matches is merged over, with no unique constraint needed or implied. And a mapped key with no matching column is an addition rather than an error, so a run that starts returning one more field does not fail — where Supabase refuses, because adding a column there is a schema change on a database Argus is a guest in.
It is never the default destination, deliberately. A saveRows step has to name it, so nothing you wrote against your own database quietly starts filling a dataset instead. The full catalogue of the others is on databases and files.
Datasets are not on the local API. The endpoints cover profiles, proxies, cookies, automations, schedules, connectors and skills, and there is no dataset route among them — your own code cannot read or write a table from outside the app. The in-app assistant reaches them directly, by name, and automation steps write into them, so the tables are driven from inside Argus rather than over HTTP.
Reading a page without a browser
The reach step fetches a page without opening one. It picks a channel from the URL, or you name one:
YouTube, Reddit and RSS answer structured rows — one per video, post or item — while web answers the page as markdown. The answer lands in a variable you name, and a saveRows step set to write one row per item is what turns it into a table. Two steps, no browser, no profile.
Everything reach fetches leaves from the launcher's own connection — not the profile's proxy, and not its cookies. That is what makes it fast and cheap, and it is also its limit: a login-gated page needs a real browser step, running as the identity that is signed in.
Reach sits with the other data steps on reading and holding data, beside the two that move rows in and out.
Give the results somewhere to land
The Data tab is in the launcher. A dataset is worth the most once something is filling it, so the automation usually comes first — and the calendar after that.