DocsSign inInstall Kastel
All connectors

In ClickUp, your AI reads the tasks that sit in private containers and waits for a decision on everything else.

With Kastel

Connect ClickUp and your Kastel reads the name, status, body and comments of your tasks. The right to read comes from the task's deepest private container, Space, Folder or List. When that container is open to the whole Workspace, the task is filed under no department at all and waits for an administrator's decision.

Your tasks hold what nobody wrote down anywhere else

A ClickUp task ends up holding far more than the task. The brief sits in the description, the real constraint turns up in the fourth comment, and the reason the client changed their mind can be read between two status changes. Nobody writes that down anywhere else.

An AI that reads this material answers from the actual history rather than from the version reconstructed in a meeting. It still has to reach only the tasks whose content the person it works for is entitled to see, which is what this page is about.

ClickUp exposes two surfaces, and Kastel handles them with two separate connectors, because their sharing models have nothing in common. This one reads tasks. Docs follow entirely different rules, described on the ClickUp Docs connector page. Each carries its own key, and connecting one never connects the other.

How your Kastel decides who may read a task

ClickUp nests three levels above a task, the Space, the Folder and the List, all three inside your Workspace. The cascade reads from the widest to the narrowest, and it stops at the first doubt. The logic is the one behind the Asana connector, with one difference that matters, the depth of the container.

  1. It reads the task's Space

    When the Space is not private, it is visible to the whole Workspace. The real audience is then a population ClickUp does not break down into named people, so the task stops there and waits for an administrator. This is the commonest case in a ClickUp nobody has tidied up.

  2. It walks down to the deepest private container

    A private Space can hold a private Folder, which can hold a private List. The members of the lowest level are the ones who decide, because they form the narrowest share. A private List therefore overrides its Folder, and a private Folder overrides its Space.

  3. It drops any member it cannot resolve

    Only full-member roles count, owner, admin and member. A guest, a custom role, or a member whose role cannot be read maps to nobody in your organisation, and the task waits. A member with no readable address produces the same outcome.

  4. It refuses to choose between two departments

    When the members it kept all belong to the same department, the task is filed under that department. When they span several departments, or none of them can be resolved, the task waits for an administrator. Assignees never enter this calculation, because being assigned to a task is not the right to read it.

A task's text, without your custom fields

A task comes into your Kastel as plain text, which rules out a good part of what ClickUp can handle from the start.

What your Kastel reads in ClickUp

  • The task's name and its current status
  • The task's description, as plain text
  • The task's comments, in their text version
  • The names of the assignees, as context
  • The private container's members, read to decide who is entitled

What it never reads

  • A task's attachments and images
  • The values of your custom fields
  • Time tracked and estimates
  • Checklists and dependencies between tasks

Assignees are written down as context and never as a permission. A task's audience comes from its container, which stops a simple reassignment from moving the task from one department to another without anyone intending it.

What ClickUp tells us about a List, and what it does not

For a private List, ClickUp's interface returns the people who have explicit access to that List. It does not unfold the access inherited from the Folder, the Space or the team. The member list we get can therefore be shorter than the task's real audience.

That direction of error suits us. An underestimated audience produces a narrower share, and the only visible effect is a task that waits for a decision instead of coming in too fast. When the shape of a member listing leaves any doubt about whether it is complete, it counts as uncertain and the task waits as well.

ClickUp is also the tool where you invite a client into a List without opening the rest to them. The practice is healthy in ClickUp and treacherous for a connector, because a guest looks a great deal like a member. A guest maps to no department in your organisation, so their mere presence in the listing is enough to put the task on hold.

A reshare does not change a task's date

ClickUp can say which tasks have moved since the last pass, and the connector leans on that filter, List by List. It is thriftier than a full reread, and it is enough to follow the text of a task.

It is not enough to follow its permissions. Adding or removing a member on a Space, a Folder or a List does not change the update date of the tasks concerned. A reshare therefore leaves no trace in the change feed, and a task would keep for ever the department it was first filed under.

That is what the periodic reconciliation is for. It recomputes each tracked task's audience from its containers' current membership, and refiles the ones whose audience changed. Between two reconciliations, a reshare has not yet been taken into account, and we write that down rather than leave it out. A change to the text, on the other hand, is refiled on the very next pass. What an administrator decides about a waiting task is recorded, like the rest of what governs your knowledge.

What this connector does not do

It does not work inside ClickUp. No task is created, moved, commented on or closed, and the client it uses exposes no write method. A connected AI knows what a task holds, it cannot move that task along.

Most ClickUp Spaces are open to the whole team, because that is how the tool installs itself. For as long as they stay that way, their tasks wait. Unblocking them happens in ClickUp, by making the Space private and naming its members, or in your Kastel, by deciding department by department. Neither of those two moves happens on its own.

The permission reconciliation runs on its own cadence, not on every pass. A reshare carried out just after a reconciliation has no effect until the next one. We preferred that short, named window to a full reread of your entire ClickUp on every pass.

A task deleted in ClickUp is not erased from your Kastel. Your Kastel keeps it with a note that it has gone from the source, changing nothing about who may read it, until an administrator decides to erase it. That is how every connector behaves, and it also covers a task your access key can no longer read.

See what the free core covers before you connect ClickUp.

Kastel's core installs on your own infrastructure, free of charge and with no size limit, with all of its connectors. The pricing page says what it covers and what starts at the first paid plan.

See pricing
Other connectors in detail
Asana
A task's audience is the union of the members of all its projects.
monday.com
A board that reaches beyond its team is readable by nobody.
ClickUp Docs
ClickUp Docs exposes no per-doc permission, so a designated department decides.

See the full connector catalogue