Setup Guide for the Omni Integration with KeyCRM

In traditional integrations, the workflow with the CRM is predetermined. As long as your process fits within it, everything works. Omni-integration is needed when you have something unique, such as your own field, condition, or sequence of actions.

It’s a flexible way to connect your CRM to UniTalk, where you configure the data exchange logic yourself: which entities are involved, including custom ones, what rules to use when searching for a customer, which fields to populate, and which events should trigger actions. If your CRM can send webhooks, the reverse direction works as well. An event in the CRM can trigger an action in UniTalk.

In practice, it’s simple. A “Contact” button appears on the customer’s profile, and phone numbers, email addresses, and chat details are automatically populated in Web Dialer without manual copying.

Flexibility means that the integration will do exactly what you specify, so it’s best to configure it systematically, step by step. That’s exactly how this guide is structured.

To connect the Omni integration, go to your personal account and navigate to API and automation → Omni-integrations.

You can also open the page using the following link:

https://my.unitalk.cloud/api-automation/omni-integrations

And click “Connect” next to the integration you need.

After clicking “Connect”, you will see the fields required for the integration to connect and function, namely:

API Key
Subdomain
Telephony webhook URL

We will now take a detailed look at where to find the required data.

1. In the CRM system, navigate to “Settings / Communications / Telephony” and click “Add new service”.

2. Next, in the opened window, you need to:

• Enter a “Title” for the channel (in any format).
• In the “Phone service” field, select Other.
• In the “URL to initialize call” field, paste the following link:

https://api.unitalk.cloud/tracking/crmConnector/directCall/KEYCRM?type=initialize

The first tab following the “Connection Settings” section is “Integration Entities.”

On this tab, you need to select the CRM system entities that the Omni integration will interact with. For the selected entities, the integration will be able to perform searches, create new records, and update existing ones during operation.

Available Entities for KeyCRM

The Omni integration supports standard KeyCRM entities: 

• Order
• Company
• Lead
• Customer

On this tab, you will find the core system management options. It contains:

• General integration settings: Activation and the primary rules for how the systems interact.
• General settings for integration entities: Behavioral logic for created or updated CRM elements.
• Operator assignment: Linking and mapping managers between the UniTalk account and the CRM.

Call Visualization in CRM

“Show standard CRM widget for inbound/outbound calls” feature: If your CRM system’s API supports displaying a standard pop-up window during calls and this checkbox is enabled, the system will automatically show it to the operator.

Additional Display Settings in the SIP Client:

• “Display the person for incoming calls in the SIP client” field: This feature works identically to the setting of the same name in our legacy integrations. When enabled, the operator will see the name of the manager assigned to this client in the CRM directly within the SIP client during an incoming call.
• “Entity priority for CRM cling and display responsible in SIP client” setting: Clicking this button adds a dropdown menu (select field). In this dropdown, you can select one of the integration entities that you previously enabled on the 2nd tab.

How priority works:

The higher a selected entity (deal, lead, contact, etc.) is positioned in the list, the higher its priority for the system when determining the responsible manager and triggering the “cling” feature.

For each individual entity you activated on the “Integration Entities” tab, the system will automatically create a dedicated control block. These blocks will be displayed in the following format: “Entity — entity_name” (for example: Entity — Order, Entity — Customer, etc.).

Inside each of these blocks, you can configure the detailed operational logic specifically for that data type.

Call History and Synchronization with Entities

Quick search links for objects will be completely hidden from the interface in two cases:

• If your CRM integration is currently completely disabled.
• If the specific entity (for example, a lead or a company) was not previously activated on the 2nd settings tab.

Web Dialer Settings and Features

In the settings section for each entity, two important parameters are available for working with the Web Dialer:

• “Send to Web Dialer during inbound/outbound calls” dropdown fields: When this feature is enabled, the name of the found object, the assigned manager’s name, and a direct link to this object in the CRM will be displayed directly within the Web Dialer during calls.
• “Show ‘Contact’ button in CRM” checkbox: Checking this box enables a “Contact” button to appear on the specific object’s page in the CRM when using the Web Dialer.

How it works: When the “Contact” button is clicked, the system automatically collects all available customer information (phone numbers, email address, existing chat ID, or data to create a new one) and transfers it to the dialer. This allows the operator to instantly call or message the client directly from the Web Dialer interface.

This serves as a modern alternative to standard click-to-call from the CRM. It runs stably, eliminates the need to develop complex and expensive custom CRM widgets, and enables sending messages via chats, SMS, and Viber directly through the Web Dialer.

Default rules of entities search for calls

These settings allow you to set default object search rules separately for chats and separately for calls.

The system automatically applies these rules in the following cases:

• During dynamic value search for event handling. If an entity is not found based on the rules specified in the action profiles, the system will perform a search using the default rules. Chat rules will be applied for chat events, while call rules will be used for all other events.
• To display information in the SIP client. To show the operator the name of the found object and the assigned manager, the system always uses the default search rules for calls.
• When configuring the “cling” feature in inbound call scenarios. The default search rules are automatically applied as the baseline configuration.
• When creating new or not yet configured actions. Chat rules are automatically applied for chat events, and call rules are used in all other cases.

Working with CRM Fields and Selecting Dynamic Values

CRM systems usually contain a large number of custom or legacy fields that are not used in telephony operations. To ensure the system runs quickly and stably, we do not retrieve absolutely every single field when fetching data via the API.

Fields with predefined integration logic are always fetched by the system automatically—you will not see them in the selection list.

Why this matters: This is crucial not only for event handling but also for configuring the integration across all subsequent tabs, as they rely on these dynamic values. If a field is left unchecked here, it will simply be unavailable later on.

Fields available by default (without checking the boxes):

• Entity ID
• Entity creation time
• Entity last update time
• Entity owner
• Main text fields: first name, last name, middle name, title, subject 
• Primary phone
• Primary email
• “All phones” — this is our system pseudo-field (created automatically within the UniTalk code) that collects and records numbers from absolutely all phone fields of the entity.
• “All emails” — a similar pseudo-field that collects email addresses from all fields of the entity.
• Pipeline 
• Link to another entity — a field where the value is the ID of a related item (for example, the link between a deal and a contact). It is usually named after the corresponding entity: “Contact”, “Deal”, etc.
• All fields with the “phone” data type
• All fields with the “email” data type
• All fields that are required when creating an entity in the CRM.

Operator locations settings

In this section, you configure the connection between managers in your CRM and users in the UniTalk system. The configuration is presented as a table, where each column represents specific data:

• 1st Column (CRM Username): Displays or allows you to select a specific manager from your CRM system.
• 2nd Column (UniTalk Users): A dropdown list to select the corresponding UniTalk user. The same UniTalk user cannot be assigned more than once in the table. Limitation: Multi-select is supported, allowing you to choose multiple UniTalk users that correspond to this manager.
• 3rd Column (SIP Lines): A dropdown list to select the specific SIP line that will be assigned to this user. The same SIP line cannot be added to the table more than once. Limitation: Multi-select is supported for SIP lines, meaning you can assign multiple lines to a single manager.
• 4th Column (Mobile Numbers): An input field for entering operators’ mobile phone numbers. If there are multiple numbers, separate them with commas. Limitation: Numbers must be valid GSM numbers. The same phone number cannot be entered in the table more than once.

Dynamic Values Available on the Tabs

To keep the interface clean and avoid information overload, each tab displays its own tailored set of dynamic values. We have removed most of the fields that are irrelevant to the current event and would guaranteed remain empty.

“Event Handling” Tab: Absolutely all dynamic values are available, except for the “Omni-integration — authorization data” block and legacy values from the “CRM” category.

“Chats” Tab: Values from the following sections are available: “Miscellaneous”, “Chat”, “Analytics” (standard), “Omni-integration”, “UniTalk Contact Book”, “Call exists in call history”, “First call data”, “Last call data”.

“Calls” Tab: Field filtering here is fine-tuned specifically for each event:

C2C Order Event: “Miscellaneous”, “Click to call”, “Analytics”, “Omni-integration”, “UniTalk Contact Book”, “Call exists in call history”, “First call data”, “Last call data”.

Outbound Call Events: “Miscellaneous”, “Call”, “Omni-integration”, “UniTalk Address Book”, “Call exists in call history”, “First call data”, “Last call data”.

Inbound Call Events: The most extensive set, including: “Miscellaneous”, “Call”, “Click to call”, “Analytics”, “Omni-integration”, “IVR”, “Auto-dialer”, “Auto-dialer number data”, “Voice bot”, “UniTalk Contact Book”, “Call exists in call history”, “First call data”, “Last call data”.

To help you easily monitor system operations, each action profile features a clear indicator. The way names and statuses are displayed depends on the selected tab:

“Calls” and “Chats” Tabs

On these tabs, you will always see the complete list of available standard events. The profile name here always matches the name of the event itself (e.g., “Inbound call — answered”).

Right next to the name, one of three statuses will be displayed:

• Not configured — you have not yet defined the rules and logic for this action profile.
• ON — the profile is fully configured, active, and successfully executing the specified actions.
• OFF — the profile is configured but has been temporarily disabled by the user (all defined actions for this event will be paused).

“Event Handling” Tab

Since you create your own custom automation scenarios on this tab, the display logic is slightly different:

• Instead of a system event, it always displays the custom profile name you provided during its creation.
• A profile can only have two statuses — ON (active) or OFF (deactivated). There is no “Not configured” status here, as every manually created profile already contains defined logic.

• Name — the profile name.
• Import “Auto-start” toggle: If enabled, the import will trigger automatically based on the “When to run” settings. (Only displayed after the settings are saved).
• “When to run import” — specifies exactly when to trigger the automatic import. There are 2 options available:
  • Set a specific time for the import to run automatically every day (this can be used, for example, to transfer phone numbers into a calling campaign);
  • Define a recurrence interval (in minutes), counted from the last run. For example, you can use it like this: if the pipeline value is 1 or 2, add the number to Call Campaign 1; if the pipeline value is 3, add the number to Call Campaign 2.

• Search by time field — searching for entities is only possible using fields with a “Date & Time” data type.
• Time from, Time to — the time range for the search. You can specify one or both search boundaries (optional). You can input either an exact time or a relative time range (e.g., last 24 hours).
• Event handlers — allows you to select up to 10 event handlers to be triggered in the future.
• Find related objects before executing actions — during the import, data from a related object will also be fetched and considered. For example, when importing a deal, we also need to retrieve the phone number stored within the associated contact.
• Save entity processing time to a field — allows you to record the time when the entity was sent for event handling (rather than when the processing was completed) into any available field.
• Reprocess entity if more than N days have passed — if the timestamp in the field mentioned above is older than N days, the entity becomes eligible for reprocessing.
• Pause between CRM API requests (sec) — a mandatory delay between API calls, ranging from 1 to 15 seconds.
• Do nothing if conditions are met — entity field conditions used to filter out and skip entities that require no actions.

Manual Import Execution

After saving the import settings, a “Start Import” button will appear, allowing you to launch the import manually right away. The import operates based on the following logic:

1. Entities are fetched from the CRM using filters based on the time field, with a limit of 50 entities per single API request.
2. Each discovered entity is processed in a queue. The system checks whether a “Processing time” timestamp is recorded for the entity. If it is, and the “Reprocess entity if more than N days have passed” setting is either empty or the specified N days have not yet elapsed, the system skips the entity and does nothing.

On this tab, you can configure the processing of inbound webhooks using event handlers. Processing can be configured for each entity, depending on the selection made in the “Integration Entities” section.

Inbound webhooks operate slightly differently from those used in some legacy integrations:

• Legacy Integrations: A phone number was passed within the webhook. The system used this number to find a contact or lead and, depending on the scenario, added the number to a calling campaign or removed it from the list.
• New Functionality: Every webhook is strictly tied to a specific entity. Therefore, the CRM must pass the corresponding entity ID within the webhook. For example, if a webhook is configured in the Deals section, it must transmit the Deal ID.

The entity search is performed by its ID. If necessary, the system can also locate related entities and utilize them for further processing.

A webhook must be sent using either the GET or POST method. (Support for other HTTP methods can be added if required; however, there is currently no such necessity).

The request must contain the entity identifier. It can be located in:

• URL query parameters;
• Request body in JSON format;
• Request body in form-data or x-www-form-urlencoded format.

The identifier must be passed in a parameter named id or entityId. The parameter name is case-insensitive, so variations like ID, EntityId, ENTITYID, etc., are fully valid and accepted.

The “Find related entities before do actions” option allows you to specify an entity that will be additionally checked for compliance with the criteria before the handler is triggered.

The “Do nothing if conditions are met” feature allows you to configure specific conditions under which this event handling profile will not be triggered.

Configuration on the KeyCRM Side

1. Go to “Settings” -> “Advanced”, then switch to the “Automation” tab and click “Add Trigger”.

2. In the trigger creation window, fill in the main parameters:

• In the “Title” field, enter any name for the trigger, for example, “Webhook on order status change”.
• In the “Event” field, select the entity type for which the webhook will be sent, as well as the specific change. For instance, select “Order / Order status change” and choose the required value, such as “Manufactured”.
• In the “Time” field, leave the value as “Immediate” so that the webhook is sent right after the status changes (or, if necessary, set a delay specifying how many minutes after the event the trigger should fire).
• In the “Conditions to execution” block, click “Add condition group” and add at least one condition. For this example, we will use a condition based on the order status. Our condition will look like this: Order status — includes — “Manufactured”.
• In the “Actions” block, click “Add action”.

4. The next step is to configure the webhook submission settings:

• Webhook URL: Paste the URL you previously copied from your personal account settings for the corresponding handler profile.
• HTTP Request Method: Select POST.

After configuring the settings, click “Add” at the bottom of the window.