A monday.com board is not a project
A monday.com board is a grid of columns that anyone composes as they see fit. On the same account, one board tracks job applications, another lists suppliers, a third holds a pay review, a fourth serves as an incident log. Nothing in the structure says which is which.
That is what makes the tool flexible, and it is what makes an AI plugged into it harder to handle. A column called Status holds one word, a column called Comment holds a paragraph, and a column called Package sometimes holds an annual figure. All three look alike when they are read through a programming interface.
The connector does not try to work out what a column means
The connector reads the item's name, the displayed text of each of its columns and the body of its updates, then turns all of it into a single text. It asks for neither the column's type, nor its settings, nor the structured value sitting behind it. It classifies nothing by content.
That limit deserves to be stated plainly, because it has a direct consequence. No filter will recognise a pay column and set it aside. The text comes in with the item, and the whole protection then rests on one question, which is who has the right to read that board. That is the difference between adjusting a share inside a tool and governing what each AI is allowed to see.
It is also why the rule applied to boards is strict to the point of looking excessive.
A column's displayed text, without its type
The connector asks for three things from an item's content, its name, the text of its columns and the body of its updates, plus its modification date so it knows what has moved. The rest is not filtered after reading, it is never asked for.
A board's subscribers are read as a permission rule, never as content. They serve to work out who may read the items, and monday.com sets no permission on an item itself, which leaves the board's audience as the only signal.
What we get asked about sensitive boards
Is a recruitment board treated differently from the others?
No, and that is the important part. The connector does not recognise it as a recruitment board. What decides is its audience. If that board is strictly private and all its subscribers belong to the same department, its items are readable by that department alone. As soon as a subscriber from another department is on it, nobody reads that board any more.
And if that board is shared with an external recruiter?
monday.com distinguishes three kinds of board. A private board is reserved for its subscribers. A shareable board opens up to guests. A public board is visible to the whole organisation. Only the first is resolved from its subscriber list. The other two are filed in no department, and their items wait for an administrator's decision.
Why refuse a board whose kind simply comes back unknown?
Because that kind is the only signal a monday.com board carries about how wide its audience is. A list of forbidden kinds would let through anything not on it, including a value monday.com might add later. So the connector allows one value only, the strictly private board, and it refuses everything else.
What happens if the subscriber list comes back incomplete?
It is walked to its last page. When a page leaves doubt about whether the list is complete, or when a subscriber has no address your organisation can resolve, the board's items are filed nowhere. An incomplete list of permissions authorises nobody.
Adding a subscriber changes no item
Resharing is the moment a connector becomes dangerous. Someone adds a subscriber to a board, the audience widens, and nothing on the items moves. They keep their last-modified date, and monday.com emits no per-item signal for a subscriber change.
An incremental refresh therefore cannot see that change. The connector runs a second pass, the reconciliation pass, which takes every item already known, recomputes its board's audience from the subscribers of the moment, and refiles the item when the result differs. A narrowed board takes the item away from the department that no longer has a right to it. A widened board puts it on hold.
That pass is also the one that refuses to conclude too quickly. When the walk through a board's items stops on a cursor that repeats itself, the missing items are not treated as deleted, and the incident is recorded. You will find the same caution across the other sources in the catalogue, because it is written once for all of them.
What this connector does not do
It does not work inside monday.com. No item is created, moved or updated, no column is filled in, no automation is triggered. The transport it uses only knows how to read.
It reads text and loses the grid. A column's displayed text comes in, its type and its settings stay out. A plugged-in AI can therefore tell you what an item says, without knowing how your board is built or what your statuses mean relative to one another.
Nothing sorts an item by its content. If your team has put a pay review in a text column, it comes in with the item, and only the board's audience protects it. That is why a board whose subscribers span two departments ends up read by nobody.
An item deleted or archived in monday.com is not erased from your Kastel. Your Kastel keeps the item while noting its disappearance at the source, and its readers stay the same until an administrator decides to erase it. That behaviour is shared by every Kastel connector, and it is better known before you connect anything.
Tell us what your boards actually hold.
A monday.com account often mixes project tracking with subjects that are not handled on a web page. Tell us which boards you would want to connect, and we will tell you plainly which ones will stay on hold.
Describe your case
