Integrations hub
The integrations hub is the single place where the business connects external channels and systems so they work together with CRM: messengers, website forms, telephony, document exchange, and your own applications. A connected channel stops living on its own: incoming messages, leads, and calls become inquiries with an owner, a pipeline, and a history.
The hub is in the CRM → Integrations section (route /crm/integrations). The form builder opens right next to it, at /crm/integrations/forms.
A single connection workflow
Every connector is connected the same way, in working terms:
- Add. Pick a connector type from the catalog and go through the step-by-step wizard. You can often choose a ready-made business scenario so you don't have to configure everything by hand.
- Configure. Fill in the main fields; advanced transport and authorization parameters stay hidden until you need them. You can save the configuration as a draft and come back later.
- Test the connection. Run a check — it shows whether the connection is healthy and gives a clear reason if something is wrong.
- Enable. Save the connection with the active toggle. For the web widget and forms, this step also generates the code to embed on your website.
- Status and health. Every connection card has a state: active and healthy, warning, error, draft, archived, or disabled. It tells you at a glance which channels need attention.
- Work flow. Each type has its own working screen: lead counters for forms, a request log for the REST integration, sync jobs for document exchange, and delivery health and a retry queue for messengers.
Who sets it up
The integrations hub is an administrator-level setup, not a daily employee action. Viewing the catalog is available with read permission for communications; creating, changing, testing, and deleting connections requires write permission (the portal administrator has full access). Without write permission the hub opens in read-only mode: you can see the connectors, but the wizard, the connection test, and the toggles are unavailable, and attempting them shows a message about insufficient permissions.
Connector catalog
The catalog lists the types of external connections your portal supports. The set of types keeps growing and can differ between installations, so always check the exact list in the catalog itself at /crm/integrations rather than in this article. The main connector families are described below.
In some deployed interface versions, a connector card may temporarily show an internal technical name instead of a user-facing label. This does not change the connector type or its permissions, but the view must not be treated as localized screenshot evidence or published before the UI is fixed and visually reviewed.
The catalog and the connections filter are grouped by direction of work: document exchange, chats and messengers, forms, telephony, mail, programmatic access (REST), and portal sign-in. The groups make it easier to find the type you need when the catalog holds many of them.
Document exchange
- Document exchange (SBIS) — integration with the SBIS electronic document management operator: outgoing drafts are prepared from the document card, statuses and signed copies are pulled in, and incoming documents are matched to a client. This is a regional connector for Russia. See the Document exchange (SBIS) page for details.
- Diadoc — a second electronic document management operator for Russia. The purpose is the same: outgoing documents, signing statuses, and matching incoming documents to a client.
Chats and messengers
- Telegram bot and MAX bot — two-way conversational channels: incoming messages from the messenger are attached to CRM inquiries and chats, and replies go back out through the connector.
- WhatsApp — a messenger conversational channel with the same logic: the customer's message becomes an inquiry with an owner and a history.
- Chat widget — an embeddable chat window for your website: a visitor writes from the site, and the inquiry appears in the shared CRM flow. The wizard requires at least one allowed domain without a protocol; it also lets you choose a work group, workspace, and pipeline, configure the pre-chat form, and get the embed code after saving.
- Chat webhook — intake of messages from an external chat system via webhook, when there is no ready-made connector for it.
Forms and leads
- Website form — one-way intake of leads from an external form via webhook: leads turn into inquiries by the chosen scenario — straight into CRM, screened first, or local only.
- Website forms (built-in module) — the portal's own forms, which you build and publish without a developer. They have no separate setup in the hub: the "Open forms" button leads to the form builder, and the card in the hub shows lead and CRM error counters. See also Forms.
- Surveys — collecting answers from a survey form into the same incoming flow.
Surveys are a separate builder for inbound requests. In CRM → Integrations, create a survey, add steps, configure options and contact fields, then review Publish and Submissions. Add allowed website origins before publishing. The portal provides a public link and popup/inline embed code. Publish and unpublish are separate actions that may be refused by readiness checks or an error; deletion requires a second confirmation. Archiving is not available in the UI. The public page works without sign-in and chooses button language from the visitor’s locale. The current public phone field forcibly converts every input to Russian +7 format regardless of the visitor’s locale or country, so an international number can be altered. Until this is fixed, do not collect phone numbers through a survey or treat this field as localized or screenshot-ready. Use synthetic questions, origins, and answers; never publish tokens, real contacts, or working links.
Communication and mail
- Telephony — a card for an external phone provider and CRM rules for incoming calls. The current wizard cannot choose a routing target; until that field exists, do not treat a connected provider, incoming routing, or CDR as available.
- Mailbox — connecting a work mailbox so that correspondence with the customer reaches CRM instead of staying in one employee's personal mail client.
Programmatic access and sign-in
- External REST integration (API key) — programmatic two-way communication: an external system creates and updates tasks and deals over the API with an access key, acting as a dedicated service account with minimal permissions. See the External REST integration page for details.
- Single sign-on (OIDC) — employees signing in to the portal through your corporate authentication system. This is a portal-wide administrative setting: it changes how people sign in rather than how leads flow, so agree it with the administrator before enabling. See Single sign-on (OIDC) for connector checks and one-time-secret handling.
AI is configured separately: connecting external language models and assistants — see AI and scenarios.
Current telephony limitation in the hub: the connector card is available, but the wizard does not show a routing target—queue or direct user. The server rejects saving a route without that target; pipeline settings are a separate layer. Until the field exists, do not treat the provider as connected or promise incoming routing, a queue, fallback, or CDR. The scenario remains source-blocked and planned.
Connectors at a glance
| Connector | Direction | What you need to connect | What to monitor after enabling |
|---|---|---|---|
| REST integration | Two-way (via API) | An API key, a service account with minimal permissions | Connection status, exchange errors, and incoming events |
| Telegram bot / MAX bot | Two-way (conversation) | Bot token, intake address | Conversations, delivery errors, and retries |
| Two-way (conversation) | Channel provider access, intake address | Conversations, delivery errors, and retries | |
| Chat widget | Two-way (conversation) | At least one allowed domain without a protocol, plus embed code; optional pre-chat and routing | Inquiries and conversations created from the website |
| Chat webhook | Incoming messages | Intake address and access for the external chat system | Accepted messages and processing errors |
| Website form | One-way | Intake address, source name, token | Accepted leads and processing errors |
| Form builder | One-way | Build the form inside the portal | Accepted leads and form readiness |
| Surveys | One-way | A survey form and an answer-intake rule | Accepted answers and processing errors |
| Telephony | Catalog and limited wizard | Provider and pipeline; no routing target | Does not prove a connection, routing, or CDR |
| Mailbox | Two-way (email) | Access to the work mailbox | Correspondence per customer and retrieval errors |
| Document exchange (SBIS) | Two-way (documents) | Operator login/password, legal entity, environment | Exchange statuses for documents |
| Diadoc | Two-way (documents) | Operator access, legal entity | Exchange statuses for documents |
| Single sign-on (OIDC) | Portal sign-in | Details of the corporate sign-in system | Whether employees can sign in |
The table covers the main families, not the full list: the set of types in your portal's catalog may be broader.
Good practices
- Give each connection a clear name and run the connection test right away, instead of enabling it "blind."
- For each channel, assign a pipeline, a starting stage, and an owner, so a lead doesn't sit there without anyone responsible for it.
- Check statuses regularly: a channel with a warning or error means lost leads and messages.
- Don't show real tokens, keys, passwords, and embed code in screenshots, and don't forward them.
Related pages