Условия в диспетчере

Условия являются важной составляющей частью правил в Диспетчере. Условия делятся на обязательные и дополнительные. В блоке Обязательные условия вы можете указать несколько через "или", тогда как в блоке для дополнительных условий можно использовать также "и". Таким образом при выполнении обязательного условия и одного из дополнительных перечисленных через "или" выполнится действие. 

 

Рассмотрим подробнее какие условия входят в обязательные:

  • Новая заявка – условие выполняется при создании заявки;
  • Новый ответ в заявке – выполняется, при написании ответа в заявке;
  • Новый комментарий в заявке – выполняется, при написании комментария в заявке;
  • Изменения в заявке – выполняется, если в заявке были сделаны изменения (смена типа, статуса, приоритета, индивидуальных полей, темы заявки, исполнителя и т.д.);
  • Изменения создателя заявки – выполняется, если в заявке изменяется её создатель;
  • Достигнут SLA (срок выполнения заявки) – выполняется, при истечении времени SLA, которое было задано в заявке;
  • Заявка объединена;
  • Разморозка заявки – выполняется при разморозке заявки;
  • Заморозка заявки до первого ответа – выполняется при заморозке заявки до первого ответа (в случае, если время и дата не указаны);
  • Заморозка заявки до даты – выполняется при заморозке заявки до определенной даты;
  • Упоминание пользователей в ответе @ – выполняется при упоминании пользователей в ответах с помощью функции @ + имя (почта) пользователя;
  • Упоминание пользователей в комментарии @ – выполняется при упоминании пользователей в комментариях с помощью функции @ + имя (почта) пользователя;
  • Добавлена оценка –  
  • Минут от последнего ответа – выполняется при достижении указанного времени с момента последнего ответа в заявке;
  • Минут от последнего комментария – выполняется при достижении указанного времени с момента последнего комментария в заявке;
  • Минут от последнего изменения – выполняется при достижении указанного времени с момента последнего изменения в заявке.

 


Внимание! Условия "Минут от последнего..." имеют следующие особенности:

 

1) Правила с такими условиями проверяются в промежутке 1-20 минут. Это означает, что если время условия указано, например, 60 минут, то правило, при выполнении всех обязательных и дополнительных условий, сработает в промежутке 60-81 минуты.

 

2) Последний ответ/комментарий обязательно должны быть совершены пользователем вручную - добавление и изменение этих параметров с помощью диспетчера не будет учитываться правилом с условием "Минут от последнего ответа/комментария". 

Это же касается и "Минут от последнего изменения". Изменения в заявке должны быть совершены не системой, а пользователем (или от имени пользователя). Изменением не считается добавление ответа или комментария в заявку. Изменения - это смена статусов, приоритетов, индивидуальных полей, исполнителя и т.д. В том числе изменения по API считаются за изменения для Диспетчера.

 

3) Самый первый ответ в заявке (т.е. изначальное обращение которое создало тикет) не является триггером для условия "минут от последнего ответа", а значит в момент создания заявки таймер запущен не будет. Условие будет выполняться только для всех последующих ответов.

 

4) В закрытых (выполненных) заявках отсчёт продолжается не более чем 3 суток (4320 минут). Если вы поставите больший промежуток времени, то в закрытых заявках правило не сработает.

 

5) Если правило или группа правил с условием "минут от..." были отключены после события (комментария, ответа, изменения) в заявке, то правило не сработает. Убедитесь, что правило и группа, где оно находится, включены, и выполните условия еще раз, чтобы заново перезапустить таймер.


 

Дополнительные условия :

  • Параметры заявки:
    • Время события - выполняется при срабатывании в указанный промежуток времени;
    • Время создания заявки;
    • Группа исполнителя заявки - выполняется, если группа исполнителя заявки совпадает с указанной;
    • День события - выполняется при срабатывании в указанный день недели;
    • Департамент – условие выполняется в случае если у заявки указан (или не указан) определённый департамент;
    • Достигнут лимит времени - выполняется при достижении отведенного времени работы с компанией, которое указано в настройках компании в системе;
    • Заморозка заявки – выполняется при заморозке заявки;
    • Заявка без подзаявок;
    • Заявка является подзаявкой;
    • Заявка является родительской;
    • Исполнитель заявки – условие выполняется если владельцем заявки становится (или не является) указанный сотрудник;
    • Источник заявки – выполняется при совпадении источника заявки (откуда именно она поступила в систему) с указанием: из системы / почты / формы или API / чата / каналов соцсетей или мессенджеров;
    • Метки заявки – проверка на наличие меток в заявке. Указываются через запятую;
    • Название заявки – проверка названия заявки на указанную фразу (например, в случае если в названии заявки упоминается слово Срочно, то выполнять определённое действие);
    • Название или содержание заявки – проверка названия или содержания заявки на указанную фразу (например, в случае если в заявке упоминается слово Срочно, то выполнять определённое действие);
    • Оценка заявки – проверка выставленной оценки;
    • Приоритет заявки – дополнительный фильтр по указанному приоритету;
    • Содержание заявки – проверка содержания заявки на указанную фразу (например, в случае если в теле заявки упоминается слово Срочно, то выполнять определённое действие);
    • Статус заявки – дополнительный фильтр по указанному статусу;
    • Статус исполнителя заявки – проверка статуса сотрудника;
    • TO адресаты исходного письма – проверка КОМУ (to) было направлено письмо. При этом копии CC/BCC - не проверяются.
    • Тип заявки – фильтр по типу заявки;
    • Эл. почты адресатов – при отправке ответа или в момент создании заявки диспетчер делает проверку на соответствие эл-почты адресатов в поле "кому" (to), включая сс и bcc (если электронных адресов несколько).
    • Дата и время события по SLA плану выполняется если событие произошло в рабочее/нерабочее время в рамках выбранного SLA плана;
    • Группа инициатора заявки – выполняется, если группа инициатора заявки совпадает с указанной. Не путать с "группой создателя заявки" - инициатор это тот, кто фактически создал её, но при этом в блоке "Клиент" (создатель заявки) может быть указан совершенно другой пользователь.

 

  • Содержание заявки:
    • Автор последнего комментария – выполняется если автором последнего комментария является указанный: создатель заявки, исполнитель заявки, клиент либо сотрудник;
    • Автор последнего ответа – выполняется если автором последнего ответа является указанный: создатель заявки, исполнитель заявки, клиент либо сотрудник;
    • Группа автора последнего комментария – выполняется если группа автора последнего комментария является указанная в условии;
    • Группа автора последнего ответа – выполняется если группа автора последнего ответа является равна указанной в условии;
    • Количество комментариев;
    • Количество ответов;
    • Наличие файлов в первом ответе – выполняется проверка на наличие или отсутствие файлов в первом ответе заявки;
    • Последний комментарий отправлен – выполняется проверка пользователя, кому или от кого был добавлен последний комментарий: Сотруднику, Партнеру либо От партнера;
    • Содержание последнего комментария – выполняется проверка содержимого последнего комментария на наличие определенных слов или фраз (например, "срочно");
    • Содержание первого комментария - выполняется проверка содержимого первого комментария на наличие определенных слов или фраз (например, "срочно");
    • Содержание последнего ответа – выполняется проверка содержимого последнего ответа на наличие определенных слов или фраз (например, "срочно");

 

  • Создатель заявки:
    • Группа создателя заявки – выполняется, если группа создателя заявки совпадает с указанной;
    • Компания пользователя – проверка организации (компании) создателя заявки (например для установки ответственного лица, для определённой компании (клиента));
    • Полное имя пользователя – проверка на соответствие пользователя (создателя заявки, клиента) указанному имени в условии;
    • Э-почта пользователя – проверка на соответствие эл-почты создателя заявки;
    • "Название индивидуального поля контакта" – проверка на соответствие указанной информации в кастомном поле карточки пользователя.

 

  • Изменения в заявке:
    • Изменение департамента – выполняется при изменении с указанного департамента на другой;
    • Изменение исполнителя – выполняется при изменении с указанного исполнителя на другого;
    • Изменение исполнителя по группе – выполняется при изменении с указанной группы исполнителя на другую указанную;
    • Изменение приоритета – выполняется при изменении с указанного приоритета на другой;
    • Изменение произвел – выполняется при изменении в заявке создателем заявки/исполнителем/клиентом/сотрудником. 
    • Изменение статуса – выполняется при изменении с указанного статуса на другой;
    • Изменение типа – выполняется при изменении с указанного типа на другой;

 

  • Индивидуальные поля – выполняется при выбранном значении кастомного поля;

 

  • Изменение индивидуальных полей – выполняется при изменении значения кастомного поля.

 


В условиях и действиях диспетчера вы можете обнаружить "Временные поля". Что это такое и зачем они нужны?

 

Основная идея данных полей состоит в том, чтобы заменить индивидуальные поля, которые создаются только под задачи диспетчера, а также для хранения временной информации. Например, состояние диалога или какие-либо промежуточные данные, которые не являются триггерами.

 

Временные поля имеют тип текстового поля, их можно распарсить по шаблону, заполнить вручную через диспетчер и в дальнейшем использовать как тег или условие к исполнению правила (а в некоторых ситуациях может использоваться в качестве замены для меток по условиям диспетчера).

 

Примеры использования временных полей могут быть самые различные. Наиболее оптимальный способ их использования в правилах, где нужно временно записать и хранить данные, и при этом их главное преимущество в том, что их не нужно отдельно создавать как индивидуальные поля, и соответственно не нужно будет хранить лишнюю информацию. Пример использования временных полей при построении чат-бота можно найти по ссылке.

 

Еще одним полезным примером является запись во временные поля ответов от вебхуков: можно будет отправлять вебхук, получать ответ от внешних систем и хранить/использовать его во временных полях:

 

 

Хранятся данные внутри временных полей в формате ключ-значение.

 

Условия:

 

 

Действия:

 

 

Разберем последний скриншот немного подробнее:

1) Ключи. Рекомендуем использовать стандартные латинские символы.

2) Значения. Заполняются также, как и текстовое поле. В случае, если устанавливается значение из диспетчера, то можно использовать теги, и записать туда какую-либо информацию по заявке.

3) Пример использования. Шаблон тега будет следующим: "temporary_field:key", где key - это условный ключ из пункта 1.

 

Ограничения и дополнительная информация:

1) максимальная длина ключа составляет 50 символов, длина значения - 1000;

2) временные поля хранятся определённый период: 7 дней от последнего изменения;

3) изменение временных полей не может быть триггером даже как изменение заявки, т.к. это дополнительные атрибуты. Соответственно под триггеры рекомендуем по-прежнему использовать индивидуальные поля;

4) временные поля нельзя использовать в отчётности;

5) эти поля нельзя получить никаким доступным способом, кроме как использовать их в качестве тега или условия/действия диспетчера;

6) по временным полям не осуществляется поиск.


 

В случае, если у Вас возникнут какие-либо вопросы по условиям, либо созданных условий Вам не достаточно для создания желаемого правила – смело обращайтесь в нашу службу поддержки, мы найдём решение для Вас!