Shared inboxes and channels
How a shared inbox differs from a connected channel in CloudFly Helpdesk, and why every conversation belongs to exactly one inbox at a time.
These two words get swapped for one another more than any other pair here, partly because the console prints the single label Channels over both. They name two roles of one record, and pulling the roles apart answers most questions about who sees what.
An inbox is the queue
An inbox is where conversations land. It carries its own display name, avatar, sender identity and greeting. Every conversation stores the id of the inbox it belongs to, and the queue you open each morning is those conversations gathered together.
The inbox is also what access is drawn around. The channel filter on the queue, the By channel entry in the left column, the reach of an AI agent: each one cuts along inbox lines. A record rule inside a permission group can be written against that same field, so "this team sees the website queue only" is a sentence the configuration can express.
A channel is the route a message travels
A channel is the technical path that carries messages into that inbox. Each type keeps its own configuration table and its own way of receiving traffic:
| Channel type | Customer messages arrive through | Configuration worth remembering |
|---|---|---|
| Website widget | The chat panel embedded on your site | The list of domains allowed to embed it |
| Facebook Page | Meta's webhook | Connected through the deployment's own Meta app |
| Zalo OA | Zalo's webhook | Self-renewing tokens; unused for three months means reconnecting |
| Telegram | A webhook of its own per channel | The public address has to be reachable |
| An IMAP synchronization loop | The sync may run on one process only | |
| API | POST /messages | For integrations you write yourself |
Channel configuration decides whether a message gets in at all. Inbox configuration decides who sees it once it is in.
Today both roles live on one record
The channel wizard creates the inbox and the channel configuration in a single pass, and the inbox record holds exactly one channel type with one configuration. That is why the Channels list shows one row per pair, and why the glossary maps both ideas onto that one label.
To pour one source into two queues, or two sources into one queue, you create two channels today. The console offers no way to detach a channel from its inbox and reattach it somewhere else.
A conversation belongs to one inbox
A conversation is stamped with its inbox id at birth, taken from the channel the customer wrote in on. It stays there for life: no control moves a conversation to another inbox, and no endpoint does either.
The practical consequence is that a customer who writes from two sources gives you two conversations rather than one. What ties them together is the contact behind them, not the queue.
Deleting a channel takes every conversation that landed in it: the foreign key from conversation to inbox is set to cascade on delete. A channel you have merely stopped using is better left in place.
Read next
What the system is made of
The three services behind the CloudFly Helpdesk console, the path a message takes through them, and why losing the realtime link is not losing a message.
Conversations versus tickets
What a conversation holds, what a ticket holds, which of the two carries an SLA clock in CloudFly Helpdesk, and how to decide where a request belongs.