Instructions for Setting Up Omni Integration for Zoho CRM

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.

Now that our application is installed in ZohoCRM, we can begin connecting and configuring the Omni integration.

To connect the Omni integration, go to your personal account, select “API and Automation” → “Omni Integrations.”

You can also open the page using this link:
https://my.unitalk.cloud/api-automation/omni-integrations

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

This guide will detail how to connect Omni integration to the ZohoCRM CRM system.

1. Connection

To log in to the CRM, click the “Connect” button.

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

On this tab, you need to select the CRM entities that will be used by the Omni integration and save the settings. For the selected entities, the integration will be able to search, create, and update records during operation. 

Available entities for Zoho CRM

The Omni integration supports working with standard Zoho CRM entities:

• Vendors
• Meetings
• Tasks
• Ordered Items
• Purchase Orders
• Sales Orders
• Calls
• Campaigns
• Quotes
• Contacts
• Accounts
• Leads
• Cases
• Quote Line Items
• Purchase Order Line Items
• Invoice Line Items
• Price Books
• Products
• Solutions
• Deals
• Invoices

On this tab, you will find the main system management parameters. It includes:

• General integration settings: activation and basic rules of interaction between systems.
• General integration entity settings: logic for the behavior of created or updated CRM records.
• Operator locations: linking and matching managers between the UniTalk personal account and the CRM.

Call visualization in CRM

“Show the standard CRM widget during incoming/outgoing calls” function:
If your CRM system API supports displaying the standard pop-up window during calls and this checkbox is enabled, the system will automatically display it to the operator.

Additional SIP Client Display Settings

• “Display the responsible manager during incoming calls in the SIP client” checkbox:
  This function works similarly to the same setting in our previous integrations. When enabled, the operator will see the name of the manager assigned to this client in the CRM during an incoming call in the SIP client.
• “Entity priority for the ‘sticky’ feature and responsible manager in the SIP client” setting:
  Clicking this button adds a selection field (drop-down list). In it, you can select one of the integration entities that were previously activated on the second tab.

For each individual entity that you activated on the “Integration Entities” tab, the system will automatically create a separate management block. These blocks will be displayed in the format: “Entity — entity_name” (for example: “Entity — Call”, “Entity — Lead”, etc.).

Inside each of these blocks, you will be able to configure the logic for working specifically with this type of data in detail.

Call history and synchronization with entities

Links for quick entity search will be completely unavailable in the interface in two cases:

• if the CRM integration is currently fully disabled;
• if a specific entity (for example, a lead or an account) was not previously activated by you on the second settings tab.

Web Dialer Settings and Features

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

• “Send to Web Dialer during incoming/outgoing calls” checkboxes:
  If this function is enabled, then during calls the Web Dialer will display the name of the found entity, the name of the responsible manager, and a direct link to this entity in the CRM.
• “Show the ‘Contact’ button in CRM” checkbox:
  If this checkbox is enabled, then when using Web Dialer, a “Contact” button will appear on the page of the corresponding entity in the CRM.

Purpose of the functionality:
After clicking the “Contact” button, the system automatically collects all available customer information (phone numbers, email address, existing chat ID, or data required to create a new chat) and transfers it to the dialer.

This allows the operator to instantly call or message the customer directly from the Web Dialer interface.

This is a modern replacement for the standard click-to-call functionality from CRM. It works reliably, does not require the development of complex and expensive custom CRM widgets, and also allows sending messages via chats, SMS, and Viber directly through Web Dialer.

These settings allow you to separately define default entity search rules for chats and calls.

The system automatically uses these rules in the following cases:

• When searching for dynamic values for event processing.
  If an entity is not found according to the rules specified in the action profiles, the system will perform a search using the default rules. For chat events, chat rules will be used, and for all other events, call rules will be used.
• For displaying information in the SIP client.
  To show the operator the name of the found entity and the responsible manager, the system always uses the default search rules for calls.
• When configuring the “sticky” functionality in incoming call scenarios.
  Default search rules are automatically applied as the basic settings.
• When creating new or not yet configured actions.
  For chat events, chat search rules are used automatically, while in all other cases, call search rules are applied.

Select with checkboxes the fields that you need to use in dynamic values for event processing.

Working with CRM fields and selecting dynamic values

CRM entities usually contain a large number of additional or outdated fields that are not used in telephony operations. To ensure fast and stable system performance, when receiving data through the API, we do not retrieve absolutely all fields.

Fields that already have internal integration logic built on them are always retrieved automatically — you will not see them in the selection list.

This is critically important not only for event processing but also for further integration configuration on all subsequent tabs, since dynamic values are used there. If you do not select a required field here, it will simply be unavailable.

Which fields are available by default (without selecting checkboxes):

• Entity ID.
• Entity creation time.
• Entity last update time.
• Responsible person for the entity.
• Main text fields: first name, last name, middle name, name, subject (usually available by default, but there may be exceptions depending on the CRM).
• Main phone number.
• Main email address.
• “All phones” — our system pseudo-field (created automatically in UniTalk code), which collects and stores numbers from all phone fields of the entity.
• “All emails” — a similar system pseudo-field that collects email addresses from all entity fields.
• Pipeline.
• Link to another entity — a field whose value is the ID of a related item (for example, linking a deal with a contact). Usually, it has the name of 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.

3.2. Operator Locations Settings Section

Allows you to configure the mapping between CRM users, UniTalk users, SIP lines, and operators’ mobile numbers.

Operator Locations Settings

In this section, you configure the mapping between managers in your CRM and UniTalk system users. The settings are presented as a table where each column corresponds to specific data:

• 1st column (CRM User Name):
  Displays or allows you to select a specific manager from your CRM system.
• 2nd column (UniTalk Users):
  A drop-down list where you select the corresponding UniTalk users. The same UniTalk user can be specified in the table only once.
  Restriction: Multi-selection is available, allowing you to select multiple UniTalk users associated with this manager.
• 3rd column (SIP Lines):
  A drop-down list where you select SIP lines that will be assigned to this user. The same SIP line can be added to the table only once.
  Restriction: Multi-selection is available for selecting SIP lines. Multiple SIP lines can be assigned to one manager.
• 4th column (Mobile Numbers):
  A field for entering operators’ mobile phone numbers. If there are multiple numbers, separate them with commas.
  Restrictions: Numbers must be valid GSM phone numbers. The same phone number can be specified in the table only once.

Action profiles are the automation section within Omni integrations. They define: 

• how exactly the system searches for entities in the CRM;
• what actions it performs with them after the search;
• according to which rules fields are filled in;
• how the schedule of responsible managers is distributed by default.

Action profile anagement is performed on the following three tabs:

1. Call Integration
2. Chat Integration
3. Event Processing Integration

4.1. “Calls” and “Chats” Tabs (Standard Events)

Here you configure action profiles for basic system events.

Available chat events:

1. Chat start
2. Chat end
3. Chat field update

Available call events:

1. Incoming call — start
2. Incoming call — answer
3. Incoming call — end
4. Outgoing call — start
5. Outgoing call — answer
6. Outgoing call — end
7. Scheduled C2C (Click-to-Call)

Key differences in call processing logic compared to previous integrations Click-to-Call (C2C)

In previous integrations, when a scheduled C2C call was created, entities were created automatically and a standard comment was added to them.

In Omni integrations, this automation is not available: you now configure the call processing scenario yourself and define which actions should be performed.

Event separation

Previously, all six call events were processed within a single general algorithm.

Entity creation for outgoing calls was controlled by one common setting, and the algorithm itself was executed only once per call:

• at the moment the call was answered;
• or, if there was no answer, after the call ended.

Configuration flexibility

In the new integration, each call event is configured independently.

If necessary, entities can be created for each event:

• up to two times for an incoming call;
• up to three times for an outgoing call.

However, it is recommended to use this capability carefully to avoid:

• data duplication;
• creation of unnecessary entities;
• possible errors in the CRM.

Recommendations for configuring action profiles

To ensure stable system operation, configure action profiles as follows:

• For call answer events, add a condition so that the profile is executed only if the call was answered.
• For call end events, add a condition so that the profile is executed only if the call was not answered.

4.2. “Integration: Event Processing” Tab

This tab is designed for creating custom automation scenarios.

By clicking the “Add” button, you can create any number of action profiles, assigning each one a clear and convenient name.

Available dynamic values on tabs

The set of available dynamic values depends on the tab and the type of event.

“Event Processing” Tab

This tab provides access to almost all system dynamic values, except:

• the “Omni integration — authorization data” block;
• outdated values from the “CRM” category.

“Chats” Tab

For chat processing scenarios, the following groups of dynamic values are available:

• Miscellaneous;
• Chat;
• Analytics (standard);
• Omni integration;
• UniTalk Contact Book;
• A call exists in call history;
• First call data;
• Last call data.

“Calls” Tab

For call events, the list of available values is automatically generated depending on the event type.

Click-to-Call (C2C) order event

Available groups:

• Miscellaneous;
• Click to call;
• Analytics;
• Omni integration;
• UniTalk Contact Book;
• A call exists in call history;
• First call data;
• Last call data.

Outgoing call events

Available groups:

• Miscellaneous;
• Call;
• Omni integration;
• UniTalk Contact Book;
• A call exists in call history;
• First call data;
• Last call data.

Incoming call events

The most complete set of dynamic values is available, including:

• Miscellaneous;
• Call;
• Click to call;
• Analytics;
• Omni integration;
• Voice menu;
• Dialing campaign;
• Dialing number data;
• Voice robot;
• UniTalk Contact Book;
• A call exists in call history;
• First call data;
• Last call data.

4.3. Action Profile Statuses and Display

The display of action profiles and their statuses depends on the selected tab.

“Calls” and “Chats” Tabs

These tabs always display the complete list of standard events. The name of each profile matches the name of the corresponding event, for example “Incoming call — answer”.

One of three statuses is displayed next to the profile name:

• Not configured — no event processing logic has been configured for this profile yet.
• ON — the profile is configured, enabled, and performs all defined actions.
• OFF — the profile is configured but temporarily disabled. While the profile is in this state, actions related to this event will not be executed.

“Event Processing” Tab

This tab is used to create custom automation profiles, so the display logic is different.

• Instead of the system event name, the profile name specified during creation is displayed.
• Only two statuses are available for such profiles:
  • ON — the profile is active and executes the configured logic.
  • OFF — the profile is disabled and temporarily inactive.

The “Not configured” status is not available for custom profiles because each profile is created manually and is initially intended to implement a specific automation scenario.

5. Entity Import

This section is used to import entities from CRM, filter some of them according to entity field conditions, and execute event handlers for those fields that match the specified conditions.

CRM Entity Import
Import is designed for automatic searching of entities in CRM and transferring them to event handlers according to defined rules.

General Settings

Name
The name of the import profile.

Auto-start
Enables automatic import execution according to the selected schedule.
The setting becomes available only after saving the import profile.

When to start the import
Defines the automatic launch schedule. Two modes are available.

• Daily at a specified time
  The import will run once a day at the selected time. This mode is convenient, for example, for daily transferring new phone numbers to a dialing campaign.
• After a specified interval
  The import runs at the specified frequency (in minutes). The countdown starts from the moment the previous execution of this profile is completed.

Example:

• Deals from pipelines 1 and 2 are automatically transferred to dialing campaign №1;
• Deals from pipeline 3 are transferred to dialing campaign №2.

Therefore, when running by interval, the actual execution time may differ from the configured one (for example, instead of 15 minutes, the import may start after 20–25 minutes).

Search by Time Field

CRM field used to search for entities.

Only fields of the “Date and Time” type are available for selection.

Time From / Time To

The time range within which entities will be searched.

You can specify:

• only the beginning of the period;
• only the end of the period;
• both limits simultaneously.

Both exact date and time values and relative values are supported, for example:

• last 30 minutes;
• last 24 hours;
• last 7 days.

Processing Settings

Event Handlers

Allows you to select up to 10 event handlers that will be executed sequentially for each found entity.

Find Related Entities Before Executing Actions

Before launching handlers, the system additionally loads related entities.

For example, when processing a deal, the related contact will be automatically retrieved, allowing its phone number or other data to be used in handlers.

Save Entity Processing Time to Field

Writes the current date and time of transferring the entity for processing into the selected field.

The system records the exact moment when the entity is placed into the processing queue, not the moment when handlers execution is completed.

Process the Entity Again If More Than N Days Have Passed

Allows previously processed entities to be processed again.

If more than the specified number of days has passed since the previous processing, the entity will be processed again. Otherwise, it will be skipped.

API Settings

Pause Between CRM API Requests (sec)

Defines the delay between consecutive requests to the CRM API.

Required parameter.

Allowed values: from 1 to 15 seconds.

Exceptions

Do Nothing If Conditions Are Met

Allows you to define conditions under which the found entity will be skipped and will not be processed.

This is useful when certain categories of records need to be excluded from automatic processing.

Manual Launch

After saving the profile, the “Start Import” button becomes available, allowing you to manually start the import at any time.

Import Workflow

After launching, the import performs the following actions:

1. Searches for entities in CRM using the selected “Date and Time” field and the specified range.
2. Loads found entities in batches of 50 records per one API request.
3. Sequentially places each found entity into the processing queue.
4. Checks the “Processing Time” field:
   • if the field is empty — the entity is sent for processing;
   • if the field is filled and repeat processing is not configured — the entity is skipped;
   • if repeat processing is configured, but fewer days than specified have passed since the previous processing — the entity is also skipped;
   • if the specified period has passed — the entity is processed again.
5. Checks the conditions from the “Do Nothing If Conditions Are Met” section. If at least one condition matches, further processing is stopped.
6. If the “Find Related Entities Before Executing Actions” option is enabled, related records are additionally loaded (for example, a contact associated with a deal).
7. Records the current time in the “Processing Time” field.
8. Sequentially executes all selected event handlers.

This mechanism allows you to safely automate CRM data processing, prevent duplicate processing of records, control API load, and flexibly configure automation scenarios.

6. Incoming Webhooks

his section is used to configure the processing of incoming webhooks using event handlers.

The configuration is performed separately for each entity selected in the “Integration Entities” section. For each entity, a dedicated processing profile can be created, and one or more event handlers can be assigned. These handlers will be triggered when a webhook is received.

Working Principle

The operation mechanism of incoming webhooks differs from the implementation used in previous versions of integrations.

In older CRM integrations, the CRM system sent a phone number in the webhook. The system searched for the corresponding contact or lead using this phone number and, depending on the configured scenario, performed the required action — for example, added the number to a call campaign or removed it from the campaign.

In the new mechanism, each webhook is linked to a specific CRM entity. Therefore, instead of a phone number, the CRM system must send the identifier (ID) of the entity for which the webhook was triggered.

For example:
• if the webhook is configured for deals — the deal ID must be provided;
• if the webhook is configured for contacts — the contact ID must be provided;
• if the webhook is configured for leads — the lead ID must be provided.

After receiving the request, the system searches for the entity using the provided identifier.

If required, it can also load related entities (for example, a contact associated with a deal) and use their data during the execution of event handlers.

6.1. Webhook Requirements

A webhook can be sent using one of the following HTTP methods:

• GET;
• POST.

The request must contain the entity identifier, which can be provided in one of the following ways:

• in URL parameters;
• in the request body in JSON format;
• in the request body in form-data format;
• in the request body in application/x-www-form-urlencoded format.

The identifier must be passed in a parameter with one of the following names:

• id;
• entityId.

Character case is not taken into account, therefore the following variants are considered equivalent:

• id;
• ID;
• Id;
• entityId;
• EntityId;
• ENTITYID.

If the CRM system does not allow using the specified parameter names, support for additional parameter names can be implemented if required.

6.2. Creating a Processing Profile

To create a new profile, click the “+” button in the card of the corresponding entity.

After creating a profile, it is necessary to:

1. Select one or more event handlers.
2. Save the settings.

When a webhook is received for this entity, all selected handlers will be executed sequentially.

The number of event handlers assigned to a single profile is not limited, which allows creating complex scenarios for automatic data processing.

To enable the handler profile, it must be additionally activated using the switch. The same switch can be used to disable it.

Whether the profile is enabled can be immediately seen to the right of the incoming webhook profile name.

Creating a Rule

1. Click the Create Rule button.

2. In the Module field, select the entity type. It must match the entity type whose URL will be used for the incoming webhook on the UniTalk side.

For example, if a profile has been created for the Contacts entity in the UniTalk account, the Contacts module must also be selected in Zoho CRM.

3. In the Rule Name field, specify an arbitrary name for the rule. It is recommended to use a clear name that will make it easy to identify the purpose of the rule in the future.

8. In the webhook parameter settings window:

• Specify a name for this action.
• Select the HTTP method: GET or POST.
• Paste the previously copied webhook URL.

9. Then configure the transfer of the client identifier using one of two methods.

Method 1. Passing via a Query Parameter

• Add the id parameter.
  • As the parameter value, select the entity identifier from the dropdown list (using the # symbol), for example Lead Id or Deal Id.

Method 2. Passing Data in the Request Body (for the POST Method)

If you have selected the POST method, you can also configure the Request Body as follows:

• Switch the mode to User-defined.
• Select the JSON data format.
• Manually create the list of fields that will be sent to UniTalk.

Using the # symbol, you can add any dynamic CRM record fields to the request body, for example:

• phone number;
• email address (Email);
• assigned manager;
• UTM tags;
• and other entity fields.

This allows UniTalk to instantly receive the full context of a lead or deal and execute the required data processing scenario.