A shared inbox has no owner
An address like contact@ or billing@ is read by several people, and usually by several departments. Sales answers a prospect there, finance picks up an invoice, support takes an incident. None of the three owns the inbox, and that is the whole point of the tool.
That absence of an owner changes the underlying question. On a personal mailbox the answer is obvious, and it is what the Gmail connector page describes: the business mail that is kept is filed under the department of the person whose mailbox it is. A Front inbox belongs to nobody, so the scope has to be read somewhere else. The connector reads it in the inbox's membership.
Where the conversation lives, and who may reread it
Every row can be checked in Front itself, by opening the settings of the inbox concerned and the list of its members.
| The conversation in Front | Who may reread it through a connected AI |
|---|---|
| In a shared inbox whose members all belong to one department | The people in that department |
| In a shared inbox whose members span several departments | Nobody, until an administrator decides where to file it |
| In two inboxes at once, whose members span several departments | Nobody, until an administrator decides |
| In a private inbox | Nobody, until an administrator decides |
| Marked private in Front | Nobody, until an administrator decides |
Four rows out of five end up on hold, and that is the intended behaviour. The rule behind them fits in one sentence: when an inbox's membership does not point at a single department, your Kastel refuses to choose on your behalf. An administrator's decision, by contrast, is recorded, which is what separates it from a setting changed on a Friday evening. The principle holds for every source and is described on governing your knowledge.
The message, without the internal comment
A shared inbox is talkative, and the connector keeps little of it. Here is the boundary, as it is written in the code.
Internal comments are not filtered out, they are not requested. The connector only calls for a conversation's list of messages, which makes the exclusion structural rather than a setting somebody has to remember.
Private content is sorted channel by channel
A Front inbox receives email, but also SMS, WhatsApp messages and live-chat conversations, all in the same list. The connector takes that into account where it matters, in the examination each message goes through before anything is written.
An email message is examined under mail rules, its correspondents' addresses included. A consumer address or an unsubscribe header is enough to keep it out. A message arriving from chat, SMS or WhatsApp is examined as a conversation, without those signals, because a phone number says nothing about the register of what was written.
Each message is handled on its own, and each becomes a separate document in your Kastel. So a discarded message does not bring down the whole conversation, and a business exchange sitting inside an otherwise personal thread still comes in. A website chat like Crisp works the other way round, where the thread is judged as one block.
With no sorting model connected, reading does not start at all. The refusal is loud, and nothing is taken in while a model is being configured.
What your teams say alongside is not requested
Front keeps two things apart inside one conversation. There is the message exchanged with the correspondent, and there is the comment your teams address to each other alongside it, invisible to the client. The connector only asks Front for the messages.
The internal comment is often the most candid place in a shared inbox. It is where someone writes what they think of a client, what they suspect about a case, what will not go into the reply. It stays out, and it stays out because it is never requested, not because a filter removes it afterwards.
The formatted version of a message stays out as well, along with its attachments. What comes in is the subject, the plain text of the message, and the correspondents' addresses or numbers, which are what tells you who the exchange is about.
Front does not say what changed, so rereading works differently
A Front message carries no modification date you can rely on. The connector therefore follows the account's event log to learn which conversations moved since its last pass, and it rereads only those.
That log is read in pages of at most fifteen events, a Front limit you can check in its own documentation. The connector walks them to the end. A pagination that loops makes the pass fail loudly, rather than returning a partial list that would make perfectly live conversations look as though they had gone.
Removing someone from an inbox, or adding someone, changes no message. That change therefore surfaces in no conversation log, and it is the periodic reconciliation that refiles the conversations concerned. An inbox that resolved to a single department and then opens up to a second goes back on hold at that point.
What this connector does not do
It does not sort your inboxes for you. A shared address receiving two departments' mail produces an inbox whose members span two departments, so conversations nobody reads until an administrator settles it. On a large contact inbox that is the most common case, and it is the work connecting leaves with you.
Connecting uses a company token, with no individual consent step. A personal-mailbox connector asks each employee to connect their own; here a single key reads the inboxes Front lets it see, including the private inboxes it is entitled to list. Filing therefore becomes the only barrier, and it is set to block by default.
Sorting private content is a judgement, and it gets things wrong. Because the rule applied depends on the channel, two messages in the same exchange can be judged differently depending on whether they arrived by email or by WhatsApp. The error always runs towards exclusion, so a business message written in a familiar tone can stay out.
Reading is the only verb. Kastel sends no message, assigns no conversation, archives nothing. And a conversation moved to the Front trash 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. If you pull it back out of the trash, the mark clears at the next reconciliation.
See what Kastel does with the permissions already set in your tools.
The product page shows how a company's knowledge is built, filed, then exposed to the AI systems you plug in, source by source. A shared inbox is the hardest case in the whole catalogue, and it is the one that judges a context product.
See the product
