The ClickUp doc is where the method ends up living
Teams that live in ClickUp end up writing more there than tasks, the runbook for a launch, the note from a client meeting, the list of decisions taken on a project. Those docs are often the only written version of how the company actually works.
An AI that does not read them answers from nothing, or from what it knows about the world in general, which is worse. So it needs those docs, and nothing beyond what the person it works for is entitled to see in them.
Kastel handles ClickUp's docs and tasks with two separate connectors, because ClickUp exposes them through two different interfaces with two sharing models that bear no relation to each other. This one reads docs. For Lists, statuses and task comments, see the ClickUp connector. Each carries its own key, and connecting one never connects the other.
ClickUp Docs does not tell us who may read a doc
The limitation is wider here than on most sources, and it deserves naming before anything else. The interface ClickUp opens on its docs returns no list of authorised people. It exposes a single sharing signal, a flag that says whether the doc is published to the web. The permissions of the Folder or Space holding it cannot be read either.
So we invent nothing from where the doc sits. A doc filed in a space reserved for the leadership team looks, from the interface, exactly like a doc filed anywhere else. Inferring an audience from that location would assume your ClickUp folders map precisely onto your departments, which is rarely true and can never be checked from the interface.
The consequence is direct. An administrator designates the department the docs read by this connector belong to, and that department is the only one to read them. The name they give is checked against your Kastel's real organisation, so a department written in a configuration file but absent from your organisation unlocks nothing, and the docs stay in reserve. It is the same sense of caution described on the security page.
A doc published to the web falls outside that mechanism. The widest possible share does not translate into the widest possible department, so the doc is held in reserve and waits for a decision. The flag itself is read with suspicion. An unexpected value in that field counts as a public doc, and therefore as a doc that waits.
A doc becomes text, one page at a time
A ClickUp doc is a stack of pages. The connector takes each page's title and its text, in order, and turns them into a single document inside your Kastel. The text is requested as markdown, so headings and lists keep their structure instead of flattening out.
That text is all that is kept. A field that comes back in an unexpected shape, an object where the connector expects a sentence, produces nothing rather than its unfolded contents. That precaution occasionally costs a less complete pass, and it stops a whole structure from landing in your Kastel without anyone having named it.
One case is worth flagging, because it touches what stays readable at your end. When a doc is emptied of its content in ClickUp, the version your Kastel had kept is withdrawn. Emptying a doc therefore has an immediate effect on what an AI can reach, whereas deleting it produces a different outcome, described further down.
What your Kastel keeps from a ClickUp doc
Scope is described in pages and in text here, because that is all this interface makes available.
The web-publication flag is read as a permission rule and never as content. It serves to decide that a doc waits for a decision, and it does not appear in what an AI receives.
The questions we get asked about this connector
Why are there two ClickUp pages, one for tasks and one for docs?
Because ClickUp exposes two different interfaces and two sharing models with nothing in common. A task belongs to a List whose members can be read, so its audience follows from its container. A doc exposes no list of people, so its audience is designated by an administrator. Two rules that far apart do not fit inside one connector, and blending them would amount to applying the more permissive of the two.
Do all my docs end up in the same department?
Yes, for the docs this connector reads. That is a constraint of what ClickUp exposes rather than a design choice. Where a Notion workspace at least carries a Person property to lean on, ClickUp Docs carries nothing. The only other route is to designate no department at all, in which case every doc stays in reserve and each access decision is taken by hand.
What happens when a doc is deleted or archived in ClickUp?
It drops out of the live listing the connector rereads on every pass, and your Kastel marks it as gone at the source. The content already kept stays readable there by the same people as before, until an administrator decides to erase it. That is how every connector behaves, and it also covers a doc that was merely archived.
Can an AI change one of my docs?
No. The client it uses exposes reads only, and no create, update or archive method exists in it. The connector cannot write into ClickUp, whatever AI is plugged in on the other side.
What this connector does not do
It does not guess a doc's audience. ClickUp Docs does not expose it, so the decision is taken once, by an administrator, for every doc read. We did not want a connector that sorted your docs by reading where they sit, because it would look as though it worked right up to the day a doc lands in the wrong department.
The grain is coarse, and you should know that before connecting. A shared file carries its own recipients and a ticket carries its security level, whereas a ClickUp doc carries neither. The precision you get on other sources does not exist here. For genuinely sensitive docs, the cautious option is to keep them out of scope altogether.
This interface exposes no date filter, so every pass lists the whole Workspace before comparing dates. Pagination that loops or breaks off makes the pass fail rather than return an incomplete listing, since an incomplete listing would make perfectly live docs look gone. Refreshing is therefore heavier than on a source able to report its own changes.
It does nothing with tasks. Lists, statuses and task comments belong to a separate connector, with its own key and its own sharing rules, and connecting docs opens no access to tasks.
See how a document becomes governed context.
The product page walks through the whole path, from reading a source to the answer a connected AI can give, with the access decision at each step. It is the best place to judge whether the grain of ClickUp Docs is enough for you.
See the product
