Join the LadVen OS testing programRequest a demo
Skip to main content

Connecting External Channels to Chat

Channel integrations gather customer communication from different places into one working loop. The customer writes where it is convenient for them — in Telegram, WhatsApp, or through a form on the site — and the message arrives in LadVen OS chat, where the team replies, assigns an owner, and links the inquiry to a task or opportunity.

This is the foundation of omnichannel work: the correspondence is not lost in employees' personal phones, and the history stays in the portal and is available to the team.

An employee can also link their Telegram from Extranet settings: the portal shows a one-time code that must be sent to the connected Telegram bot. The code is not submitted back to the portal; refresh the bindings after the bot replies. If Telegram integration is not enabled, ask a manager to enable it. Revoke access in the same settings and then refresh the binding list.

In Telegram settings, linked does not guarantee delivery: a legacy link may require migration. A manager can start migration or ask the client to reconnect. The client sends the full /bind <code> command to the bot, then refreshes the links; the one-time code has a TTL and is never entered back into the portal. After a reload or a tab change, issue a new code. An expired code, a wrong bot/missing command, and Telegram bound to another account need different actions; an administrator must release the conflict.

External channel scenarios

External channel scenarios — conceptual guidance, not UI evidence

Telegram, WhatsApp, and website forms can feed chat when their adapter is enabled. They are not type options in the generic /chat/integrations form, which uses only external, bot, and webhook.

Right now you can connect the following to chat:

  • Telegram — messages from a Telegram bot or channel;
  • WhatsApp — messages from WhatsApp;
  • Site form — inquiries sent through a form on your website.

Each channel is connected as a separate integration. One company can have several integrations at once — for example, Telegram for one product and WhatsApp for another.

note

The set of available channels depends on your portal settings and the connected adapters. If the channel you need is not in the list, check with your portal administrator whether it is available in your configuration.

/chat/integrations configures generic external, bot, and webhook chat connections. The form has typed outbound endpointUrl and inbound inboundToken fields; optional advanced parameters are an object-shaped JSON value. Invalid JSON and non-object JSON are rejected. Delivery operations are separate at /chat/integrations/ops; Telegram and WhatsApp provider setup lives in the CRM Integration Hub and is not implied by this form.

How to Connect a Channel (for an Operator with Manage Access)

How to Connect a Channel (for an Operator with Manage Access) — conceptual guidance, not UI evidence

Users with chat.canReadSettings can view the integrations list. Creating, editing, enabling, disabling, and deleting integrations requires chat.canManageSettings. The screen can therefore be available to a non-admin operator in read-only mode.

  1. Open the chat integrations section in the settings.
  2. Create a new integration and give it a clear name — for example, "Telegram: Sales" or "WhatsApp: Support". The name lets the team understand where the messages come from.
  3. Select the connection type.
  4. Fill in the typed outbound address and inbound token, and use an object-shaped JSON value only for additional parameters. Invalid JSON or a non-object JSON value is rejected. Take exact values from the provider; the portal does not publish secrets or guess them for you.
  5. Enable the integration and save.

After saving, the integration appears in the list with its own status. You can disable or delete it in the same place, and update the parameters when the channel's access changes.

Prepare the channel parameters in advance and check them before enabling: a mistake in the token or address means messages will not arrive or be sent.

How It Looks for the Team

How It Looks for the Team — conceptual guidance, not UI evidence

Once a channel is connected, customer messages from it arrive in chat as ordinary conversations. From there the team works with them the same way as with internal chats:

  • replies to the customer right from the portal;
  • attaches files, replies to a specific message, uses mentions;
  • links the conversation to a task or opportunity so the inquiry enters the workflow;
  • pins important messages and searches the correspondence.

The customer receives replies back in their channel — they keep communicating the usual way, without knowing about the portal's inner workings.

Delivery Operations

Delivery Operations — conceptual guidance, not UI evidence

For external channels it is important that messages not only arrive but also go back to the customer. The /chat/integrations/ops console is readable with chat.canReadSettings; retrying a delivery requires chat.canManageSettings.

  • how many messages are queued, sent, failed, or overdue;
  • stuck deliveries filtered by integration, numeric limit, or overdueOnly;
  • dead-letter rows with status, attempts, maxAttempts, and the last error;
  • retry only for manage users: it updates the same delivery, its status, and attempt count instead of creating a hidden duplicate.

Regularly check the console for active channels: if the number of errors or stuck messages grows, the problem is usually in the channel's access or its limits, not in the portal itself.

On a narrow screen, the same data becomes cards: a stalled-delivery card keeps the integration, pending/failed/overdue counts, and oldest pending age visible; a DLQ card shows status, attempts/maxAttempts, the last error, and Retry. Retry is disabled without chat.canManageSettings; do not click it during capture, so the frame remains read-only and does not mutate the queue. A localized screenshot must use target-language labels, synthetic identifiers without PII/secrets, and an RTL review for ar.

Good Practices

Good Practices — conceptual guidance, not UI evidence

  • Name integrations by channel and purpose so the team immediately understands the message source.
  • Prepare and check the channel parameters before enabling the integration.
  • Assign an owner for each external channel, otherwise inquiries will be "visible to everyone" and closed by no one.
  • Link customer conversations to tasks or opportunities so the inquiry does not remain just correspondence.
  • Periodically check the delivery console for active channels.
  • When the channel's tokens or access change, update the integration parameters right away.

Common Mistakes

Common Mistakes — conceptual guidance, not UI evidence

  • A mistake in the connection parameters — messages do not arrive or are not sent, and the cause is not visible in the correspondence itself.
  • No owner for the channel — customer inquiries get lost in the general flow.
  • A conversation from an external channel is not linked to a task or opportunity — the agreement stays only in chat.
  • No one watches the delivery console — sending errors pile up unnoticed, the customer gets no reply.

Related Sections — conceptual guidance, not UI evidence