The internal note says what an agent really thinks of the case
A support ticket is one of the few places where three voices live inside a single object. The customer describes the problem in their own words, sometimes in anger, and pastes in their own order number or address as they go. An agent answers in public. That same agent writes, in an internal note, what they really think of the case, and the customer never sees that third voice.
It is also the most useful archive an AI can read in a company that sells anything. It holds every fault your product has caused, every workaround that worked, and the real reason behind the refunds. An agent who starts on Monday takes months to acquire what that archive already knows.
Both of those things are true at once. The useful question is therefore which tickets an AI may read, and on whose behalf it is working.
What the ticket carries, and what a plugged-in AI receives
Every row can be checked by opening a ticket in your own Zendesk.
| What the ticket carries in Zendesk | What a plugged-in AI receives |
|---|---|
| The description written by the customer | The same text, at the head of the ticket |
| A public reply from your agent | The same text, labelled public |
| An internal note from your agent | The same text, labelled internal |
| A reply inserted by a macro | The inserted text, never the macro that produced it |
| An attachment sent by the customer | Nothing at all |
| The group handling the ticket | Nothing in the text; that group decides who is allowed to read |
Comment formatting is not kept. The connector asks Zendesk for the plain-text version of a comment, and that is the version that comes in.
The group handling the ticket decides who may read it back
Zendesk assigns a ticket to a group, and a group gathers agents. That is the only original permission there is anything to inherit from, and the connector leans on nothing else. It expands the group into agents, identifies each agent in your organisation, and files the ticket in the department all of them belong to.
When they do not all belong to one, the ticket is filed in no department and waits for an administrator's decision. The same holds when the group is empty, when one of its agents cannot be identified in your organisation, and when the list of its members comes back without telling us whether a page was missing.
The case that surprises people is the ticket with no group. In Zendesk it is the most widely visible ticket, the one every agent can open. In your Kastel it is the least readable of all, because general visibility designates no particular department. An administrator can of course file it, and that decision is recorded like the rest of what your company decides about its own knowledge.
One last detail decides how far an incident spreads. Each group is read separately. When the access key cannot read one specific group, only that group's tickets wait for an administrator, and the pass carries on for the others. When the key has been revoked, the whole pass stops and reports an access problem. That key appears in no URL, no log and no file header, and our security page describes where it is kept. Intercom, which handles the same material, answers the question differently.
The ticket, its public reply and its internal note
The connector covers Support tickets, and nothing else in your Zendesk account.
Attachments are excluded for a concrete reason. A customer attaches a screenshot without looking at what surrounds the error, and that ranges from a bank statement open in another tab to a private conversation left visible. The text of the ticket is enough to understand the case.
The first pass goes back through your whole ticket history
Zendesk can say what has changed since last time, which is rarer among business tools than you would expect. The first pass therefore starts at the beginning of your history, with no window of a few months, and later passes reread only what moved.
The cursor marking that position never advances past a ticket that failed. When a ticket fails, the position freezes before it, and the next pass picks it up along with everything that follows it in the feed. A ticket already read and unchanged costs nothing to review.
A ticket your agents delete moves to the deleted status in Zendesk. The connector stops reading it, and the next reconciliation counts it as absent from your account.
One blind spot deserves naming. A change in a group's membership updates no ticket's modification date, and Zendesk emits no event for that change. The correction therefore happens on the reconciliation pass, which rereads every ticket and recomputes the department of each one.
What this connector does not do
It does not protect your agents' internal notes. They come in with the ticket, labelled internal, and they are readable by the department of the group handling that ticket, exactly like the public reply. The group decides for the whole ticket, never comment by comment. If your agents write things about a customer that a colleague in the same department should not read back, that is a habit to deal with before you connect anything.
It does not work inside Zendesk. No ticket is created, commented, reassigned or closed, and the transport it uses exposes one single operation, reading. A plugged-in AI can tell you what a ticket holds; it cannot answer it.
It does not correct a permission change to the second. Between two reconciliation passes, a ticket whose group changed membership keeps the department it was given. The window is short and it is real, and we would rather write it down than let you discover it.
A ticket deleted in Zendesk is not erased from your Kastel. The copy already read is marked there as gone at the source and kept, readable by the same people as before, until an administrator triggers the erasure. On a source carrying a customer's own words, that is worth knowing before an erasure request arrives rather than after.
See how content gets filed before you plug an AI into it.
The product page describes the context layer your AIs query, how a piece of content is filed into a department, and what an administrator decides. Kastel's core is free to self-host, with all of its connectors.
See the product
