Nobody knows what is inside a company's Airtable bases
Airtable is where a company files whatever does not fit into its software. Production tracking sits in one base, a project budget in another, the list of job applications in a third, and now and then a fourth holds a pay scale.
Those bases share no structure. The columns carry whatever names your teams gave them, and nothing in the tool says that a column called Salary is more delicate than a column called Status. A connector therefore cannot rely on what columns mean to choose what it reads.
The Airtable connector draws the consequence, and it is unusual in this catalogue. It reads every column of the tables it can reach, without trying to guess which ones are sensitive, and it puts the decision somewhere else, at the level of access to the base.
What each column type becomes
Every row here can be checked in your own base, by looking at the type of the column concerned.
| Column type in Airtable | What comes into your Kastel |
|---|---|
| Text, long text, number, date | The value, preceded by the column's name |
| Checkbox | A true or false value |
| Single or multiple select | The selected values, separated by commas |
| Attachment | Nothing, neither the file nor its content |
| Link to another record | Nothing of the linked row's content |
| Formula or computed field | Its value, when that value reduces to text or a number |
| A column left empty on this row | Nothing, and the row comes in shorter |
The name of the base and the name of the table come in too, so a row stays intelligible outside its grid. A value that is not plain text is left aside rather than copied across wholesale, which makes an unexpected row shorter and never more talkative.
The decision is taken at the level of the base
Airtable grants access per base, and that is where your company has already decided who works on what. The connector uses it as the read permission. It looks at a base's collaborator list, resolves it to people in your organisation, and files every row of that base in their department when all of them belong to the same one.
A single department at the end opens access. Every other situation leaves the base's rows waiting for an administrator's decision.
- The base is shared with the whole workspace, or through a share link
- Its collaborators belong to more than one department
- One of them matches nobody your organisation knows
- The collaborator list cannot be walked to the end
- The connected token is not allowed to read that list
Four kinds of column read, the rest left in the base
The Airtable connector's scope is wide across columns and narrow on anything that is not text.
An attachment stays out without exception, including when its filename gives away what it holds. The connector downloads no file from Airtable, so a contract dropped into a column stays in Airtable and nowhere else.
The last case is worth knowing before you connect
Reading a base's collaborator list depends on your Airtable plan and on the rights granted to the token. An ordinary token can be refused that read, and the connector draws the cautious conclusion. The whole base goes on hold, its rows are taken in and nobody reads them, until an administrator decides where they belong.
That is annoying on the first connection and it is deliberate. A connector that filed those rows at the mercy of a failure would be pleasanter on day one and indefensible on the day somebody checks. An administrator's decision, by contrast, leaves a trace.
A change of access on a base is caught without your having to think about it. When a collaborator from another department joins the base, its rows stop being filed in the previous department on the following pass, even though no row moved.
The surest lock is set in the token
The connector only sees the bases its access token can see. Airtable lets you pick those bases one by one at the moment the token is created. If you do not want a base read at all, the simplest way is to leave it out of the token, and that can be checked in Airtable's own token creation screen.
One point surprises people. A filtered view protects nothing. The connector asks for a table's rows rather than a view's rows, so the rows your usual view hides come in with the rest. The same holds for the columns you hid in a view, which come in as well.
Nothing travels back to Airtable. The connector cannot create, change or delete a row, because none of those operations exists in its code. And since Airtable publishes no change feed, every pass rereads the tables in full; an unchanged row costs nothing to review. Every connector sits in the free core, this one included.
What this connector does not do
It does not understand your bases. It does not know that one table tracks sales deals and another tracks job applications; it reads rows and columns. A connected AI will find the information written in your cells without inheriting the meaning your team gives to how they are arranged.
It does not guess a table's primary column. Airtable does not expose which of your columns acts as the title, so the title kept for a row is its first non-empty value in alphabetical order of column names. A table whose first column is called Amount will produce titles that talk about amounts.
It offers no list of columns to exclude. On this source, leaving out a whole base is possible, leaving out one column of a base being read is not. That is a real limit, and we would rather write it here than let you find it on the first attempt.
A row deleted in Airtable is not erased from your Kastel. It is marked there as gone at the source and kept, readable by the same people as before, until an administrator erases it. And when a base or a table stops being readable, its rows are neither marked nor retired, because losing the ability to read is not proof of a deletion.
See what a source with no structure becomes inside Kastel.
The product page shows what Kastel builds out of your tools, and where to find the trace of the decision that allows one department to read a base rather than another.
See the product
