Channels
The ways a customer can reach you, what each one can do, and what is receive only.
A channel is a way for a customer to reach you. Every channel lands messages as tickets in the same Inbox, tagged with where they came from. Channels live at Channels in the sidebar.
Receiving is not the same as replying
Read this before you connect anything. A channel can be able to receive messages and unable to send them, and the two are reported separately.
SMS and WhatsApp are receive only. Messages arrive and open tickets, and nothing in the product sends on them. A reply written on such a ticket would stay in Auralis, so the ticket screen does not offer a reply box at all. Internal notes still work.
Email can send, once the workspace has configured it. It is the one channel with an outbound leg. It needs either a connected Google mailbox, or, with platform sending switched on, a minted sending address or a verified sending domain. Until one of those exists, email sends nothing and no reply box appears on an email ticket. See Email.
Each channel card states both capabilities in words: whether it receives, and whether it sends. Trust the card rather than the presence of a connection, because a connected channel with no outbound leg still cannot answer anybody. That answer is worked out for your workspace, not fixed for the channel. The same channel can offer a reply box in one workspace and not in another.
The three groups on the page
| Group | What it means |
|---|---|
| Connected | This workspace has stored a connection. |
| Available | An adapter exists and you can connect it now. |
| Coming soon | A channel with no adapter behind it. There is no Connect button, because storing settings nothing can read is a connection in name only. |
A channel can also be Paused, which means connected but switched off by an operator, or No adapter, which means a connection was stored for a channel whose adapter is not present. The configuration is kept and starts working the day the adapter ships.
Health
Every channel card, and a banner above the Inbox, reports one of these:
- Receiving. Connected, working, and tickets have arrived.
- Waiting for its first message. Connected and working, nothing has arrived yet.
- Receiving only, replies not yet supported.
- Needs attention. Connected but disabled, or missing its adapter.
- Disconnected.
Health is computed from what the service reports plus the number of tickets attributed to the channel. That is the only evidence available that anything has ever arrived, so "has received nothing yet" is a state the product can see, and "stopped receiving" is not.
The banner sits above the Inbox on purpose. The person who notices that a channel has gone quiet is the agent working the queue, not somebody visiting settings.
Connecting a channel
Press Connect on the card. The dialog shows the channel id, what the channel can and cannot do, and its stored configuration.
Two things about configuration are worth knowing.
Credentials are never shown back to you. The service returns a short list of descriptive fields in the clear and redacts everything else, including field names nobody anticipated. A redacted value is stored, it is just not returned.
Saving replaces the whole configuration. A credential you cannot see is a credential the save cannot preserve on its own, so the dialog names exactly which keys it is about to overwrite and asks you to re-enter them deliberately. That is the difference between an explicit replacement and silent data loss.
OAuth tokens are refused here rather than redacted. They belong to the connection flow that stores them somewhere a wholesale replace cannot wipe. Email's Google connection is the example. See Email.
Disconnecting
Connecting is a write-level action. Disconnecting is admin only, so an editor can finish a setup without being able to remove one.
Where inbound messages arrive
Each channel with an adapter publishes an inbound path, shown on its card. A provider posts the message payload there and the pipeline turns it into a ticket, or threads it onto an existing one if it belongs to a conversation already open.
Messages arriving twice land once. Correlation and identity resolution belong to the pipeline, so this holds for every channel rather than being something each integration has to get right.
Tickets know which channel they came from
Each ticket carries its source, shown under the subject in the queue and used by the channel filter chips. The chips are built from what the queue reports, so a channel connected today gets a working filter without any change to the product.