A team's operational knowledge lives in its tasks
In a company that runs its work in Asana, a good share of the operational knowledge lives in tasks rather than in documents. A team writes there how an acceptance test actually goes, why a deadline moved, what the client said on the phone. Nobody then copies any of it into a tidy procedure.
An AI with no access to those tasks will therefore answer beside the point on anything operational. It will lean on whatever the company took the time to write up properly, which is a small part of what it knows. The difficulty is that an Asana task carries no read permission of its own. It borrows its audience from its projects, and that is where everything is decided.
A task's audience is the union of the members of all its projects
Asana lets one task live in several projects at once. That is a strength of the product and a serious difficulty for a connector, because the task has no list of readers and each of its projects has one. Where a Trello card belongs to a single board, an Asana task can answer to three different member lists.
Your Kastel therefore pools the members of every project the task appears in, then checks that they all belong to the same department. When they do, the task is filed in that department, and an AI working for someone in another department does not see it. When the union spans two departments, the task is filed nowhere and waits for an administrator's decision.
The shortcut would be to keep one of those projects, the narrowest or the first one listed. It would open a slow leak. Filing a task in the sales department makes it readable by the whole sales department, including people who are members of none of the projects involved. That generalisation only holds when the projects' members point at a single department, and the connector refuses to make it in every other case. This is the difference between inheriting a share and governing a context.
What your Kastel reads of a task, and what it leaves in Asana
Asana returns nothing but a task's identifier until it is asked for more. Each read therefore declares the fields it consumes, and the rest of the task is never sent at all.
Automatic events are left out for a substantive reason. Asana files the comment a person wrote and the status change the system posted in the same stream. The first carries a decision, the second states the shape of the work at one moment and goes stale on its own.
A project visible to a whole team puts its tasks on hold
An Asana project can be restricted to its members, visible to an entire team, or visible to the whole workspace. In the last two cases, the project's explicit member list no longer says who can read it, since people reach it without appearing on that list.
Your Kastel then refuses to conclude. A task living in such a project waits for an administrator, even when the explicit member list pointed cleanly at one department. Trusting that list would mean undercounting the project's real audience, and so granting access nobody decided to grant.
The same caution applies when a member list comes back truncated, when a member cannot be identified in your organisation, or when the task lives in no project at all. There is then no audience to inherit, and so no department to file the task in.
A membership change alters no task, so we recompute
Asana timestamps a task when its content changes. Adding or removing a person on a project touches neither the text of its tasks nor their modification date, and no event is emitted at task level.
A connector that settled for the feed of recently modified tasks would therefore never see a reshare. A task would stay filed in the department it entered under, long after its project changed hands. Your Kastel therefore recomputes, on a regular cadence, the audience of every task it tracks, from its projects' current members. When the result differs from what was recorded, the task is moved into the right department and the copy filed under the old one is withdrawn.
Every project tool imposes its own trade-off on this exact point, and the Jira connector rereads every accessible issue on every pass for the same reason. An edit to a task's text, on the other hand, is picked up on the very next pass.
What this connector does not do
It does not work inside Asana. No task is created, commented on, completed or moved, because the client it uses exposes reads only. One point deserves to be said plainly. Asana offers no read-only token to ask for, so that guarantee rests on how the connector is built rather than on a setting you could check in your own workspace.
It reads text and nothing else. A task whose information sits in its due date, its assignee and a custom field comes in reduced to its title, and a task with neither title nor text does not come in at all. On a heavily structured Asana, part of what you see on screen never makes it through the door.
Many tasks will stay on hold, and that is not a configuration flaw. Cross-functional projects, the ones that gather delivery and sales around the same client, produce exactly the union that spans two departments. An administrator then has to decide where those tasks belong, one by one or by rule, and that work does not go away.
The audience recomputation runs on its cadence rather than by the minute, so someone removed from a project can still reach its tasks for a while through an AI working for their department. And a task deleted in Asana, or completed and then purged, 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, exactly as in every other Kastel connector.
Start by looking at what Kastel refuses to file on its own.
The product page describes what the free core installs on your side, connectors included, and what an administrator decides next. With Asana, the list of tasks left on hold is the first useful signal, because it shows where your projects mix several departments.
See the product
