---
title: "Shared inboxes and channels"
description: "How a shared inbox differs from a connected channel in CloudFly Helpdesk, and why every conversation belongs to exactly one inbox at a time."
updated: "2026-08-28"
audience: [agent, administrator]
source: "https://helpdesk-docs.svr1.feedapp.click/en/khai-niem/inbox-va-kenh"
---

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-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-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                           |
| Email          | 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 [#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.

> **Note:** 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-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.

> **Warning:** 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 [#read-next]

* [Roles and per-feature permissions](/en/khai-niem/vai-tro-va-quyen)
* [Glossary of helpdesk terms](/en/khai-niem/thuat-ngu)
* [Create your first channel](/en/bat-dau/tao-kenh-dau-tien)