The «Triggers» User Manual

A script, also known as Rule, is the main unit of automation, which contains the logic for trigger activation.

A script can be triggered by an extensive list of actions:

1. In leads

Lead added
Lead updated
Lead responsible changed
Lead status changed

2. Contacts

Contact added
Contact updated
Contact responsible changed

3. Companies

Company added
Company updated
Company responsible changed

4. Tasks

Task added
Task updated
Task responsible changed

5. Notes

Note in lead
Note in contact
Note in company

Phone calls, SMS and emails are also counted as notes, so you can use triggers for these actions on them as well.

6. Incoming message

You can perform actions on incoming messages from chat, for example, if a customer uses WhatsApp, you can use a trigger for an automatic reply.

7. Digital pipeline

You can apply all the filters and rules of the digital pipeline in tandem with the rules of the triggers.
You can also run a script from SalesBot.

8. Manual launch

Launch from a pop-up notification with a request
Launch from the lead card
Launch from the contact card
Launch from the company card
Launch from lists of deals, contacts and companies

9. Launch from another Rule

Triggers can start other scripts so you can construct a chain of scripts according to your needs.

Interface

List of Rules is the first page you’ll see if you open the «Triggers» tab in the settings.
A Rule can be turned on and off. A disabled script will not be executed, but if there are delayed triggers, they will be executed according to the schedule.
Clicking on a green link in the Event section will display the last 100 events that triggered this Rule, the date and time of each event.

Rule setup example

To create a new script, select the event for which it should run, such as «Transaction added», enter a name, such as «Task to handle», and click «Add rule».

A window for creating a new rule will appear:

The script maker window contains:

Name - a brief name of the script. In addition, this text will be displayed in the lead, contact and company cards to manually run the script.
Description - a more detailed description so as not to forget what the script performs.
Condition block - a block divided into 2 parts. The left part has Conditions, the right part has Triggers, which will be executed if the conditions from the left block are met. You can add several blocks, and each block will be executed consecutively from top to bottom. You can change the order of the blocks by drag and drop. You can also set a timer, which will delay the execution of this condition block. The block can have its own name.
A field for selecting the scenario that will be executed if no condition block is triggered.
Timing selection - how often this script can be run. For example, a lead changes every 10 seconds, should the budget be recalculated every time or once a minute is enough. You can also set a condition that the script will only be run once for a particular entity, to do that check the «Once» box. The minimum script timing for a particular entity is 5 seconds.

Working with condition blocks:

Triggers, in a condition block, are activated only when all conditions in the block are met, otherwise the block is ignored and is not executed.
Condition blocks are executed sequentially from top to bottom. The conditions in the block itself are also checked from top to bottom. You can set a small timing for a conditional block, up to 20 seconds, for example, to wait for the fields to be filled after previous actions.
You can add several conditions to the condition block, by default conditions are validated by «AND» rule, i.e. all conditions must be met.
Inside the conditions you can select different types of data for comparison (date, time, number of leads, current day of the week, etc.), depending on the type selected, various types of comparisons may be available.
Blocks of conditions and conditions themselves can be dragged at your discretion. Executions and checks go from top to bottom.

The Rule:

We need to assign responsibility for a new request to one of the two employees. Wholesale requests go to one manager, retail requests to another. The name of the request specifies whether it is wholesale or retail, we will use it as a reference when setting the conditions.

Thus, the conditions of the task look like this:

If the lead is called «WHOLESALE form order», assign Henrique to be responsible for the deal and set a task for Henrique.
If the lead is called «RETAIL form order», assign David to be responsible for the deal and set a task for David.

The conditions:

1. Click on the «Not configured» condition line, or add a new condition if there is no such line.

2. Here we see three fields. The top and bottom are fields to be compared with each other, the middle one is the comparison operator. You can compare everything with anything, including values from related entities (e.g. the lead field compares with the related company field), dates, system fields, etc.

3. In our case we compare the name of the lead with the text value set manually - «WHOLESALE form order», if name matches this value, then triggers will be executed in this block.

4. Thus our condition looks like this:
Name> Lead> Equal> Text value> «WHOLESALE form order».

If necessary, you can add more conditions, e.g. if it is not a day off, if the lead value is not less than 1000$, etc. Conditions can be combined with each other by «AND» (all conditions must be fulfilled) and «OR» (at least one condition must be fulfilled).
Let's name this block «If wholesale».
The name will help us in the future to keep track of which blocks are triggered, which are not, as we need it for debugging.

The conditions are set, now we can add triggers, which will perform the actions we need.

The triggers:

According to the task, we need to put Henrique in charge of the transaction.
To do this, choose the «Change responsible user» trigger and configure it.

Trigger name - you can leave it blank.
Apply - select «In lead» or leave it as default, since this script is triggered from a lead.
Start timer - you can delay starting this action, but it is not required in this case, so leave with «No timer».
New responsible - here you should select an employee to whom the lead will be transferred.
Change in linked entities - you can change the responsible person in the Companies, Contacts and open tasks.

After this part is done, let's set up similar conditions and triggers for retail orders, for this we will add a new «If Retail» condition block.
All we need to do is add a condition for «RETAIL form order» (the rest of conditions are the same), then appoint David as the responsible user.

The end result with both condition blocks looks like this.

Now you can create an infinite number of automated scripts depending on the tasks in your business processes.

List of all conditions

Conditions are used to filter trigger activation in a block. For example, creation of a certain task should only take place if the lead has reached a specific status.

The list of conditions may vary depending on the entities being compared and the type of script. If, when selecting an entity, the condition disappears, then it cannot be applied, because the data type in this case may not match.

List of all comparisons

You can compare almost any data from the CRM including linked entities. In the comparison settings, both lower and upper fields have the same data, the result does not change when you rearrange them.

Trigger types

Trigger is the end result of a Rule that actually makes changes in the system: creates a lead, sets a task, changes a field, etc.

The list of triggers may vary, depending on the script in which it is executed. If you do not see any trigger, it means it cannot be run in this script.
Each trigger, depending on its type, has its own conditions.
By default, the trigger runs immediately (or queued for execution), but it can be delayed by a timer or executed at a specific date and time that is written in the required field.

1. Create lead

This trigger automatically creates a lead in Kommo.

Options:

Lead name - specifies the title of the lead. Text, numbers or variables.
Tags - sets tags for the lead, variables can be used
Responsible user - you can assign a responsible user manually or automatically.
Pipeline - specifies the pipeline in which the lead will be created
Status - pipeline stage at which the lead will be created.
Start timer - allows you to delay the activation.
When creating a new lead in a company you can also attach existing contacts of the company to it.

Example: when completing a deal, immediately create another one.

2. Create contact

The trigger automatically creates a contact in Kommo. Functionally similar to #1.

Options:

Contact name - name of the new contact. Text, numbers or variables.
Apply - you can choose which entity to attach the contact to, a lead or a company. You cannot attach a contact to a contact.

Example: when completing a deal, immediately create a contact.

3. Create company

The trigger automatically creates a company in Kommo. Functionally similar to #1.

Options:

Company name - name of the new company. Text, numbers or variables.
Apply - you can choose which entity to attach the company to, a lead or a contact. You cannot attach a company to a company.

Example: when completing a deal, immediately create a company.

4. Copy lead

Copies an existing lead into a new one with all the fields filled in. Functionally similar to #1.

Parameters:

Lead name - the default will be «[Name of the old lead] (copy)». Text, numbers or variables.
Apply - This trigger can only be applied to a lead.

5. Change fields

Changes the values of the lead, contact and company fields. Each entity has its own trigger to change the value.

Options:

Start timer - allows you to delay the activation.
Apply - each entity has its own trigger, so you cannot select an entity in this case.
Field - select the field to which you want to change the value. Select the desired field, write the value of this field in the text field. You can use any text, variables, calculations, values from other fields in the value.

This trigger also allows you, among other things, to transfer field values from one entity to another. For example, the budget lead field is transferred to the company field.

You can also use field modifiers when using this trigger: perform mathematical operations, write numbers as text, and much more.
Read more on page variables for widgets.

You can change the values of several fields in one trigger.

To write a value from another entity, use variables such as {{contact.cf(123456)}} - The value of a contact field with ID 123456
To set the values of lists and multilists, enter the exact values from those lists, separated by commas.
To clear all list values, write {reset}.
To enable or disable checkboxes and switches, type 0 or 1
To make field calculations use variables, for example: {{ (field1+field2):calc }}
For a list of system variables (current date, time, incoming call duration, note text, incoming email text, number of company deals, etc.) see here.

Examples: if the lead is completed successfully, add the lead budget to the company field; if there is an incoming call, save the duration of the conversation in seconds in the contact field.

You can also set values to the fields manually, e.g. select 500 deals and set a budget for all of them. To do this, you must first create a script with the «Your script» type, set the conditions in it (if necessary) and the trigger that changes the value of the desired field. Then select the leads and apply this script to them.

6. Create task

Adds a new task for an employee.
You can choose a version that adds the result to the task. In this case, the task cannot be closed without selecting a result, and after closing the task with a result, the next script will automatically start.

Options:

Apply - you can select the entity to which the task will be added. For example, the script is launched to create a lead, and the task can be added to the company of this deal.
Start timer - select a timer to start.
Responsible - select the user responsible for the task. By default, the responsible user is the one responsible for the entity.
Task type - select from Kommo task types.
Execution time - select the time period in which the task should be closed, for example, 1 hour.
Task text - select the task text. You may use any text, numbers, or variables.
Task result - you can add a choice of result when the task is closed, depending on the selected item, the next script can be started. If at least one result is added, the task cannot be closed without selecting a result. Scripts launched from the task must be created beforehand.

7. Change task

This trigger can change tasks by entity: change the text, open, close, change the responsible user and task type.

Works with all tasks or with the last task of a certain type. For example, if you change the lead status, you can close all tasks with a certain type. If you try to close a task without adding a result, you can open it again and add «Add task result!» to the task text.

Options:

Search tasks by type - finds all tasks by type and performs the required action
Apply for - you can apply an action to all tasks of this type or to the last task.
Responsible - you can change the responsible user.
Task type - you can change the task type.
Task status - you can change the task status, e.g., close it.
Task text - you can change the text of a task.

8. Add note

Adds a new note to the feed.
Note text -The text that will be added to the feed. You can use variables.

For example: The {{lead.sale}} deal has been successfully completed! Congratulations to you, {{client.responsible.name}}!

You can also add a system note. The system note is displayed in a small font without a frame.

9. Change tags

Allows you to add or remove a tag from a lead, contact, or company.
Add tag / Remove tag - you may add a tag or several tags separated by commas.

To remove a tag you need to know its name, you can also specify a few separated by comma.
To delete all tags, leave the field «Tag Values» blank.

10. Change status of the lead

Changes the stage of the lead in the pipeline. You can also change the pipeline itself.

Options:

Pipeline - select a pipeline.
Status - select the stage to which you want to move the lead.

This trigger can only be applied to a lead.

11. Execute Rule

You can start one Rule from another, so you can set up short chains of actions. Only manual scripts can be started with this trigger (script type when creating - «Custom Rule»)

Example: when closing a lead, you need to create one more lead in a week, but under condition that at that moment there will be no active leads on the client.

This automation can be implemented by running a manual script. When closing a deal, the manual trigger is put on hold for a week, which, after 7 days, will see if there are no other active deals and create a new one if there are no deals.

Options:

Apply - you can select what you want to run the script for. For example, you can set tags for a lead, contact or company and change the status only for deals. Take it into account when configuring manual scripts.
Rule - the script itself, which must be created beforehand.

12. Salesbot: run bot

Automatically launches the configured Salesbot in Kommo.

Options:

Apply - this trigger can be applied to a lead, contact or company.
Bot - you can choose from a list of created bots.

For example, you need to notify the client through the same channel from which he or she has contacted (e.g. WhatsApp). To do this, first create a sales bot in which the message is sent. Then run it at any stage of the pipeline on some action in the system, such as when the client's birthday has come, etc.

13. Send webhook to URL

Sends a webhook (HTTP request) to an external address on the Internet, if necessary, it can analyze the response and accept the data.

Options:

URL - the address where to send the request.
Headers - you can add your own headers to the request.
Body - add variables and their values to the request.

Request always contains: Kommo entity ID, entity type, Rule ID, triggered condition group ID. You can use variables and templates in the fields.

The trigger can analyze the response and, when it is received, run the script by sending it all the variables that came in the response. The response is analyzed for a maximum of 5 seconds.

The variables come in the {var} or {parrent_child1_child2...} format, up to 10 attachments. The entire body of the response is contained in the {webhook_data} variable, i.e. it can be displayed in a note to see all the data. Variables can be used to fill in the fields or in the conditions of condition blocks, since the system works the same way as with incoming hooks.

14. Mailer: send an email

Sends email with tracking of email opening and clicks on links. The template must be created in the Mailer widget and the widget itself must be installed.

Options:

Sender - on whose behalf the email is sent
Recipient (by deal) - if the mail is sent from a lead, you can select the recipient manually, for example, only the main contact. Otherwise the recipient is set automatically from the company and contact.
Email template - created in advance an email template with text, pictures, variables that will be sent to the client.

The email template can have its own automation triggers, for example, when you open the email or when you click on links, they will also be triggered.

15. Subscribe to the lead

Allows you to subscribe to a deal, so that its chat notifications are sent to you and other subscribers.

Options:

Subscribe / Unsubscribe - you can perform one of these actions.
Event - chat, there are no other options in this case.
Users - you can select users from the list, also user ID can be inserted to a special field via a variable.

16. Cancel delayed jobs

This trigger allows you to cancel another trigger that was scheduled for a certain time.

For example, you can cancel a delayed notification to a customer if the customer has rejected the service altogether.

A trigger deletes all delayed triggers for that entity in the selected scenario, in the selected condition block and in the specific trigger.

You can read more about delayed triggers below.

17. Change global variable

The trigger sets the value of a global variable. You can set the value, add a new value, erase the value (e.g. by sending an empty value).

You can read more about global variables further in this article.

Delayed triggers

Delayed triggers allow you to schedule the execution of a trigger for a certain time. It is through delayed triggers that tasks like birthday greetings, checking conditions after a certain time, setting tasks for the future, etc. are executed.

Each trigger has a «Start timer» option. If you specify it, the action won't be executed immediately, but will be scheduled for a certain date and time. The countdown time can be anything from 1 second to 99 years. You can also take the execution date from the lead, contact or company fields.

The timer options are as follows:

No timer - the trigger will be executed as usual without delay.
Seconds, minutes, hours, days - Trigger execution can be delayed by the number of specified units, e.g. 30 seconds or 7 days. The beginning of the timer countdown is the moment of trigger execution.
Date from lead, contact, or company field - the trigger will be executed on the specified date. For example, SMS notification of the client on the day of the appointment. You can specify the trigger time manually. You can shift this date by day. The field type must be «Date».
Day of the year from the lead, contact, or company field - the trigger will run every year on the selected date. The field must contain the standard date, e.g. 05.05.1990, so the trigger will be executed every year on the 5th of May. This way you can, for example, congratulate customers on holidays or birthdays.

«Replace delayed actions from the entity» is, while not an option, a very important parameter.

By default, a delayed action on a trigger will be placed (i.e. a new one will be added) every time the script is executed. For example, the script is this: when changing a contact, if the «birthday» field is not empty, run a delayed «congratulations» trigger. This script will be executed every time any contact field is changed.

If you entered the wrong date by mistake and saved the contact, then changed the date to the correct one and saved it again, two delayed actions will be created, one with the correct date and the other with the wrong date, then both will be executed.

To avoid this, check the «Replace delayed actions from entity» checkbox in the trigger, then each time the trigger is executed, the previous action that has not yet been executed will be deleted and replaced with the new one.

Please note that the delayed trigger is placed 1 time when the script is executed, and will be executed 1 time when that date arrives. To set the next trigger, you need to run the script again.
For example, you have set up a delayed SMS for the date from the Contact field, the script is configured to change the contact. Consequently, if there hasn't been any interaction with the contact since the first greeting, then the next triggers for greeting will not be created.
Trigger by itself will not schedule greetings for years to come. It is necessary to change the contact again, if the script was to change the contact, but this can also be done by another trigger.

You can delete a delayed trigger

For example, if the client refused to make an appointment, you need to cancel the reminder of this meeting. There is a special trigger «Cancel delayed jobs» for this purpose.
For example, if the deal went to the «Service canceled» status, you can run a trigger, in which you can select the desired script, a block of links and the specific trigger that set the delayed tasks.

The «Cancel delayed jobs» trigger removes ALL delayed triggers in that scenario in the selected condition block and in the specific trigger for that entity.

Global variables

Global variables are used throughout the system. You can store any data in them, including field values from Kommo.
Variables can be overwritten, cleared, or added to an existing value. The same variable can be used in all scenarios, including use as a condition. Variables are not bound to any Kommo entity.

The data type in a variable is always text, but you can store numbers, text, dates (as UNIX-time), 1/0 toggle switches).
The widget will automatically understand the format and correctly handle the calculation of values from a variable.
You can add an unlimited number of variables, each variable can store up to 30,000 characters.

Use examples:

Transferring field values from one lead to another
Example: you need to transfer the value of a field from one lead to another lead.
When you fill a field, you can save its value to a variable, and when you create a new lead, you can insert the value of the variable into the new lead field.
Value counter
Example: we need to count the total number of missed calls for the company.
You can add a script for a missed call, and, each time it is triggered, increase the variable value by 1. If the value of the variable exceeds 10, then you can send a notification to the head of sales.
Make a mini report
Example: you need to understand how many times a request hasn't been processed on time.
To do this we need to add a script that controls how long a lead is at a certain stage. Each time it is overdue, a new line of text is added to the variable with a reference to the lead and the responsible user. At the end of the week, the variable will accumulate many lines of data, it can be sent to any messenger and cleared for the next week.
Use in conditions
Variable values can be used in condition blocks.
For example: if the variable has a value of 1, then the scripts will work in a certain way, e.g. distribute to certain people, if 0, then to other people. That way you can change a variable in one place and all scripts start working in a different algorithm.

1. Adding a new global variable

To be able to work with a variable, it must be added beforehand. Go to the «Variables» tab, enter the name of the new variable, and click «Add variable». You can specify the value of this variable right away or leave the field empty.

At any time you can open the needed variable and see its current value directly in this window.

2. Changing the value of a global variable

You can change the value of a variable via a special «Change global variable» trigger.

Add a new trigger to your script's condition block
Select «Change global variable» from the list.
In the window that opens, select the variable that you want to change
In the «New Value» field, enter the value you want to assign to the variable, for example, «{{date.now}} - event occurred». You can use any system variables, field values, modifiers, calculations, arbitrary text, etc.

When you run this script, the value of the variable is completely overwritten with the new value, erasing the previous data.

3. Adding a text value to an existing variable value

To ensure that the text value is not erased but added to the previous value, add the variable itself in curly brackets before the new value. E.g:
{report}
{{date.now}} - the event

In this case, each time a trigger is activated, new text will be added to the variable.

4. Mathematical calculation in a global variable (counter)

To do a calculation, use the name of the variable, just like in the lead field.
Example: add one to the variable, every time it is triggered - {{ ({report}+1):calc }}

More about variable calculation here.

Make sure there is no text data in the variable, otherwise the function output might not be correct.
The variable value after the calculation, can be output in a note, for example.

5. How to set a global variable value to a Kommo field

Add a trigger to change the field, e.g: «Change lead value». In the options select the required field, in the value insert the name of the variable in curly brackets, e.g: {report}.

6. How to use a global variable in the conditions

In the condition block, add a new «Variable value» condition, select the desired variable on the right side of the field.
Select the necessary comparison and the second value. In this case, the operation method is no different from the fields.
You can do a comparison with a value from the field, with an arbitrary value, or with another variable.

Rules by trigger type

Scripts, also known as Rules, are run automatically when actions are taken in Kommo or manually. Depending on the type of events for which the script is triggered, different options and variables are available.

When creating a lead, contact or company
The script runs automatically as soon as one of these entities is created. You can run triggers that apply to this type of entity, although with some restrictions. For example, you can't create a deal with a trigger set on creating a deal, since that would cause an infinite trigger loop.

In the script conditions, on top of everything else, there are available:
- All the fields of the given entity and related entities.
- Tags, budget, responsible user, pipeline, status, etc.
- Tasks: date of the nearest task, number of tasks (open, overdue, total).
- Number of attached leads, contacts, depending on the specific entity.
When a lead, contact or company changes
The script runs automatically when any entity changes. You can work with all related entities. For example, when changing a transaction, we can change fields at the company of that transaction.

Also changes occur when changing the responsible user, adding a note, including a system note, changing tags, that is, almost any action on the entity. That is, all these actions will trigger your script, which is configured to change. It's also worth noting that entity changes can be triggered by the script itself, thereby triggering infinite execution of the script and triggers.

For example: to change a lead, we add a note and adding a note causes a change in the lead, on which the script is run again and the note is added again. The widget functionality has a basic protection against such recursions - a script timeout. The minimum re-execution time of any script for a particular entity is 5 seconds. Nevertheless, there may be cyclic scenarios that trigger each other, so be careful in building the logic.

In the script conditions, on top of everything else, all the fields of the given entity are available:
- All the fields of the given entity and related entities.
- Tags, budget, responsible users, pipeline, status, etc.
- Tasks: date of the nearest task, number of tasks (open, overdue, total).
- Number of attached leads, contacts, depending on the specific entity.
With an incoming message
The script is automatically triggered if a client writes to a chat room which is connected as a source of leads in Kommo.

For example in Telegram, Instagram, Viber, WhatsApp, Skype or in the Kommo online chat on the website.

An interesting feature available in the conditions is the text of the message. E.g.: if the message text contains «how much does it cost», you can automatically send a reply with the price as a trigger.
When the responsible user changes
The script automatically runs when the responsible person changes.
All conditions for changing the entity are available in the script conditions.
When adding/changing a task
The script runs when a task is created for any entity.

In addition to everything else in the conditions are available:
- Type of the associated entity to which the task was added
- Type of the task
- Is the task completed? (Yes/No)
- Date and time the task started, and date and time the task was finished
- Task duration
When adding a note
The script automatically runs when you add a note in a lead, contact or company.

In Kommo, adding a note occurs when:
- Adding a plain text note.
- Adding a system note.
- Incoming/outgoing SMS message.
- Incoming/outgoing email.
- Incoming/outgoing phone call.
The following conditions become available for configuring the logic:
- Note type (call, letter, sms, system, text)
- By email: email type (incoming/outgoing), email header
- By SMS: message type (incoming, outgoing), message text
- By calls: type of call (incoming/outgoing), call duration in seconds, call status (held, unreachable, busy, etc.)
Manual launch
A script is run manually by clicking a button in a lead, contact or company card. Only the triggers which are applied to the entities will be triggered correctly inside the script. Trigger buttons will only appear for the scripts of the same entity type.
For example, the button of a script associated with a lead will be shown only in the lead card.

Furthermore, manual triggering is not possible for the following types of scripts:
- Lead status change
- Responsible user change
- Add/Change task
- Adding a note to any entity
- Incoming message
For these scripts, the button in the card will NOT appear!
Launch from the digital pipeline
The script is launched from the digital pipeline. Due to the program specifics, only the following types of scripts are available:
- Create/change lead
- Manual (custom) script
All the other scripts will not be displayed when adding an action in the digital pipeline
Run from SalesBot
You can run a bot from the script as well. Only lead-related scripts and manual scripts will be available.
Start by another trigger
Launched by a trigger from another script. Variables and data from bound entities transferred from the parent script are available.
Running the script by clicking a link
The script can be launched by following a link. For example, an email or SMS with a link is sent to a client, he clicks on it, and Kommo triggers automation. Links can be sent automatically via messenger or by email.

In addition, the link can be sent in a common chat in a messenger or in a private message to yourself, e.g. for the automation.

Trigger links

You can send clients links to pages on the Internet, e.g. an offer, catalog, pricelist, and run scripts when they click on these links. The link can be sent to the client via messenger (via SalesBot), by email or with an SMS.

Making an automatic trigger link

Go to the Links tab, select the Auto link type, enter the Name and click Add link.
When the window opens, enter:

Name of the link
URL - the page you link to, e.g. your Google Doc or your website with a product catalog.
Rule - a preconfigured script that will be executed when you click on this link.

After you save it, a variable of {tglink:58} type is generated, which can be inserted into any field using the «Change Fields» trigger. Then the link can be sent to the client via an email, SMS or a messenger through SaleBot by pasting the field where the link is stored.

When the client clicks on this link, the script will start and the triggers contained in it will be executed, e.g. a task will be set or a lead will be moved to the right stage.

Manual trigger link

This link uses entity IDs substituted through variables.

First, generate the link, then substitute the desired variable with the entity ID number after the ID:

number 1 - for a contact;
number 2 - for a lead;
number 3 - for a company

Example:


https://tglk.ru/{{{contact.id}}/1/ - contact link
https://tglk.ru/{{lead.id}}/2/ - lead link
https://tglk.ru/{{company.id}}/3/ - company link

Inbound webhooks

The widget can accept incoming webhooks from various services and process them.

For example:

When filling out a form on a site by Tilda, the form can be sent to Kommo, and different scripts can be triggered depending on whether there are duplicates of the contact in Kommo. If you have a WordPress site, you can install the free WebHooks module.
When you update or unsubscribe a contact in MailChimp newsletters, you can drop the updated information into Kommo.

If the service supports webhooks, you can be sure that it will be easy to integrate with Kommo through this widget, without a programmer.

How to work with webhooks:

1. Create a webhook in a widget and copy the URL

Go to the widget settings, Webhooks tab.
In the upper right corner, enter the name of the hook, for example, «Requests from the site», click «Add».
A new hook receiver will be created and a URL of the https://tglk.ru/in/QB4PoBsADoF9e6lA type will be generated.

2. Paste the URL into a service that can send them

There are a lot of services that can send hooks, such as: website builders, mailing services, some payment gateways, messengers as well as Kommo itself (e.g. if you need to send data from one Kommo account to another).

3. Send a hook from the website, e.g. send a text request

4. Wait for the request to be accepted in the webhook's settings in Triggers and make sure that the data was received

The data that came in the request can include customer contact info, a list of goods, cookies and various tracking IDs, form names, etc.

An entity can be searched across multiple fields, and if an entity is found by at least one field, the rest will not be checked, i.e. the search is always done on the OR principle.

5. Using the incoming variables, configure the scripts in Triggers

For example: search for a contact by phone, if there is no contact, create a new one, if there is, update and set a task.

Debugging scripts

The widget has a built-in debugger, which you can use to answer the following questions:

Why didn't the script work?
Why didn't the trigger within the script work?
Why did the script work when it shouldn't have?
Why didn't the condition work?

Making an automatic trigger link

In the Rules list, click on the green link on the right (name of the event - e.g. «Lead added»).

The last 100 actions that may have triggered this script will be shown.
For example, if it is a script to create a lead, it will show the last 100 leads with their IDs.

If there isn't a single line in the list, that means that no lead has been created yet after the script was set up.
If there are several condition blocks inside the script, each block will be shown as a separate line and the triggering status of the particular block.
Find the lead for which you intended to run the script and activate the triggers (search by ID), and see how the particular condition blocks were or weren't executed.

If the lead that you are testing is not yet on this list, then the webhook has not yet reached it.
Look at the number of «Queue of events» in the Statistics tab, if it is different from zero, then this hook is probably still in the queue, it happens if a lot of hooks from Kommo come. This is the regular system activity and it's impossible to speed it in order to avoid blocking Kommo API.

A condition block can have three statuses:

1. Completed
The block was executed and activated the triggers that were set in it. You can click on the word «Completed» and see what triggers were activated inside. You can also find out why this block of conditions was triggered by clicking on its name.

2. Does not match the conditions
The block was not executed, because it doesn't fit the conditions. Click on the name of the condition block and see all the conditions and values that didn't allow this block to run.
The condition block will only execute if all lines are green, since red lines indicate that some condition hasn't been met.
If you move the pointer to the condition line, you will see more detailed information: what data came in, how it was checked, and what it resulted in, including the time it took for the check to be triggered.

3. Run frequency exceeded
This caption appears if the script was initiated more often than the script settings - «Execute for a specific entity: no more than 1 time per XX sec».

For example, this field is 60 sec. and the transaction will be changed every 10 seconds, in which case the script will be run only after the change that occurred 60 seconds after the previous change, all other changes in this range will be ignored.

Try not to lower this time limit needlessly. This directly affects the number of triggers, therefore the monthly operation limits, which are capped at 50000 per account, will be used up faster.

In general, try to use the «Lead update» scripts as little as possible, because such changes are quite frequent: any entity update, addition of a note, calls, chats, etc. cause the lead to change. Depending on the business process, try to use less «frequent» scenarios such as: status change, entity creation, adding a note, etc.

Common error codes

TECHNICAL RESTRICTIONS

Execution rate limits

Due to the amoCRM API nature, there are some limits on how fast the widget can perform operations.

For example, all the processes are queued in tasks and executed at a certain interval, which prevents the blocking of your account API. Each new task is placed at the end of the queue, so there can be delays in the execution of operations.

For example, if you are running a script for 1000 leads, depending on the complexity and number of triggers in it, the whole process will run for 5-10 minutes. All this time, the remaining processes will be queued up and will be executed when it is their turn. At the same time, a special algorithm ensures that scripts with large queues do not interfere with other scripts.
This is the standard functioning of the system, and it cannot be accelerated.

Operation count limits

To protect against the excessive use, the widget provides for counting the certain number of operations. Scripts must be configured so that there are no looping processes, duplicate operations, unnecessary triggers, etc.

There is an operation limit for each account: 50 000 operations per month for each user, e.g. for 5 users it is 250 000 operations. Each activation of the trigger and each coming webhook from amoCRM is considered as an operation. You can see the number of available operations in the Statistics tab.

This number is, on average, three times the number of operations required by an average account. However, some accounts may exceed it due to misconfiguration or complexity of the processes. If you exceed the limits a lot and often, we will help you to optimize scripts, and if it's impossible, you will need to buy the necessary number of operations. The calculation follows the same scheme - 50 thousand per user. That is, if you exceed 100 thousand per month, you will need to pay extra for 2 users.

This limit is completely manually controlled, your account will not be automatically deactivated if you exceed it. We will pay attention to this only if this happens systematically, in which case we will contact you to discuss further work.

Script count limits

There can't be more than 100 scripts per account. This number fully covers the needs, and a bigger number leads to failure from the program interface to work properly. If you have more than 100 scripts, contact us, we will see why this is the case and find a solution.
The maximum number of active scripts for changing the entities (leads, contacts, companies, tasks) must not exceed 3 per event.

Delayed trigger queue storage limits

When a delayed event occurs, the script that initiated the event may not be active (off). In this case, the delayed event will not execute and will wait for the script to turn on. If the disabled script does not turn on within 3 months from the time the pending trigger is due, the trigger is deleted.

If the script is enabled, all pending triggers that are already due will be executed immediately.

Are you having troubles with the widget configuration? Complicated business processes in your company?

Request a professional setup from Komanda F5.
Full automation of your workflow on a turnkey basis, considering the specifics of your company.

Request a setup