Есть у эволюции начало, нет у эволюции конца
Выпустив в феврале серьезно переработанные правила обработки почты, мы не планировали возвращаться к этому вопросу еще долгое время. Но со временем стало понятно, что наша попытка влить новые возможности в старую форму правил имеет много минусов. Местами настройка получилась очень запутанной, и в Службу поддержки регулярно поступали вопросы по этому поводу. А это явное указание на то, что наша работа не завершена.
Поэтому мы приняли решение сделать следующую итерацию в работе правил, которую я вам сегодня и презентую.
Давайте посмотрим, как теперь выглядит создание нового правила для почты:
Как видите, форма правила приобрела четкую структуру, чем-то напоминающую автоматические сценарии. Глаз сразу выделяет 4 раздела:
- Условия срабатывания. Тут размещен набор условий, определяющих, в каких случаях будет применяться это правило.
- Извлечение данных. Здесь мы разбиваем письмо на инфоблоки и описываем, какие данные мы хотим из него получить. В предыдущей версии правил вместо инфоблока использовался термин “Переменная”. Это было плохое решение, так как этим же термином в ПланФиксе называются переменные, которые можно использовать в шаблонах задач, документов и т.п. Теперь мы избавляемся от созданной нами же путаницы и вводим термин “инфоблок”. Инфоблок — это фрагмент текста письма. Мы извлекаем его и сохраняем для дальнейшего использования в ходе работы правила. Обычно инфоблоки служат для заполнения полей задачи, контакта или аналитики, которые создаются правилом. Чуть дальше на примерах я покажу, как это происходит.
- Основное действие. Здесь мы выбираем, что нужно сделать из письма — задачу, контакт или комментарий.
- Дополнительные действия. Здесь мы обычно описываем, какими инфоблоками, извлеченными из письма, нужно наполнить создаваемую в основном действии задачу или другой объект. А еще можем дать волю фантазии и добавить что-нибудь для души — ведь в этом разделе можно использовать практически все операции, доступные в автоматических сценариях. Так что если вам нужно отправить SMS при получении определенного письма или изменить какую-то другую задачу, это вполне можно организовать. Главное не заплутать в волшебном лесу возможностей, которые открывает этот инфоблок. Что, прямо скажу, непросто 🙂
Как это работает
Давайте рассмотрим, как работает новая итерация правил, на классическом примере разбора письма с заказом, которое генерирует наш сайт. На всякий случай, напомню: клиент заходит на сайт и оформляет заказ, сайт генерирует письмо и отправляет его в ПланФикс, в ПланФиксе создается задача-заказ, которую затем отработают ответственные за выполнение заказа сотрудники.
Для того, чтобы это письмо стало задачей-заказом, нам и понадобится правило обработки с параметрами, описанными ниже.
1. Условия срабатывания. Тут все просто, достаточно идентифицировать письма-заказы по адресу, с которых они были отправлены:
2. Извлечение данных. Для примера нам будет достаточно извлечь ФИО клиента, оформившего заказ, и состав заказа. Начнем с ФИО клиента, это будет один инфоблок:
Аналогичным образом из письма можно извлечь телефон или емейл клиента, его адрес и т.п. данные, которые в нем содержатся. Для каждого из этих параметров мы создаем инфоблок и указываем, как именно его нужно заполнять. На примере телефона:
А вот данные, содержащие несколько строк — например, состав заказа — извлекаются чуть иначе:
Такая конструкция позволяет извлечь множество наименований товаров, каждое из которых содержится в отдельной строке и заключено между заголовками “Товар:” и “Цена:”. Это упрощенный пример, в реальной жизни многое будет зависеть от того, в каком именно формате присылаются письма. Например, если товары перечислены в табличке, то скорее всего придется выбрать формат HTML и использовать в качестве меток не слова, а фрагменты HTML, которыми начинается и заканчивается ячейка с описанием товара.
В любом случае, результатом выполнения такой “множественной” операции извлечения данных в инфоблок будет набор значений. Его можно представить в виде перечня данных — в частности, наименований товара, присланных в письме. Аналогичным образом вы можете извлечь перечень цен и перечень количеств товара в заказе. ПланФикс аккуратно распарсит письмо согласно ваших настроек и сложит данные в инфоблоки. В них данные будут тихонько лежать и ждать, пока вы используете их по назначению, для заполнения реквизитов задачи, контакта или аналитики.
3. Основное действие. Тут все просто, нужно лишь выбрать что мы хотим сделать из письма:
В зависимости от выбранного варианта, вам может понадобиться задать какие-то дополнительные параметры. Но там нет ничего сложного, поэтому не останавливаемся на деталях и идем дальше.
4. Дополнительные действия. Допустим, мы создаем задачу-заказ: выбрали на Шаге 3 “Создать задачу по шаблону” и указали шаблон “Заказ”. Теперь настало время наполнить эту задачу данными из инфоблоков, которые мы получили на Шаге 2. Например, указать клиента, сделавшего заказ.
Я сразу покажу более сложную конструкцию: мы не просто запишем ФИО клиента текстом, а создадим его карточку и установим получившийся контакт в качестве контрагента задачи. Это стандартная для ПланФикса конструкция, которая наверняка вам пригодится:
Обратите внимание на средний инфоблок, в котором мы заполняем контакт значениями ранее полученных из письма инфоблоков. Здесь он играет двойную роль:
- если это новый контакт, то его ФИО и телефон будут установлены из письма;
- если у нас уже есть контакт с таким телефоном, то новый контакт создаваться не будет, система выберет существующий — но при этом дополнит его новыми данными, если их еще нет в соответствующих полях контакта.
Это позволяет не плодить дубли и аккуратно накапливать историю взаимоотношений с клиентами, которые уже обращались к вам ранее.
И еще один пример заполнения данных. Теперь это будет аналитика “Товары”, которую мы добавим к создаваемой нами задаче. На Шаге 2 мы извлекли из письма перечень товаров, которые заказал клиент. У нас получилось 3 инфоблока: “Наименование товара”, “Цена товара” и “Количество товара”:
Давайте добавим к задаче аналитику “Товары” и заполним ее этими данными. Для этого добавим в правило дополнительное действие “Добавить аналитику” и укажем, откуда брать данные:
У меня есть подозрение, что заполнение данных аналитики из инфоблока это самая сложная для понимания операция, поэтому я попробую дополнительно ее проиллюстрировать. Вот письмо, которое робот отправил в ПланФикс после оформления заказа на сайте:
После извлечения из него данных на Шаге 2, в “товарных” инфоблоках накопились такие значения:
- Наименование товара: Зажим КС6, Фиксатор U-системы, Переходник N-P
- Цена товара: 5400, 150, 390
- Количество товара: 1, 5, 3
Когда на Шаге 4 мы добавляем к задаче аналитику “Товары” и заполняем ее данными, ПланФикс берет первое значение из инфоблока “Наименование товара”, создает для него строку аналитики и заполняет ее данные первыми значениями из инфоблоков “Цена товара” и “Количество товара”. А затем повторяет это столько раз, сколько всего значений в инфоблоке “Наименование товара”. Так в задаче оказывается 3 строки аналитики, заполненные нужными нам данными:
Надеюсь, этот пример поможет вам разобраться в новом интерфейсе правил и научиться настраивать правила обработки почты для ваших бизнес-процессов.
Заключение
Хотелось бы мне написать, что на этом работа с правилами для почты завершена, но я это уже писал в старом блоге ПланФикса, еще в 2011 году:
Поэтому повторяться не буду, а просто упомяну напоследок несколько моментов:
- Несмотря на существенные изменения внешнего вида, все ваши старые правила продолжают работать. Мы аккуратно, порциями, переводили их на новый “движок” в течение лета и осени, оперативно исправляя неизбежные в ходе этой сложной операции поломки. И только после того, как переезд был завершен и прошло достаточно времени, мы сделали новый интерфейс редактирования правил доступным для всех.
- В списке дополнительных действий сохранился пункт, который позволяет работать со старыми правилами:
- Но все новые правила мы рекомендуем создавать в новом интерфейсе, используя все современные возможности ПланФикса.
Работа над правилами обработки почты будет продолжаться. Если у вас есть кейсы, которые не решались в старом интерфейсе правил, попробуйте настроить их в новом и напишите нам, чего в нем не хватает. Какие-то вещи мы знаем сами, но наверняка у вас будет чем дополнить этот список.
Кроме этого, мы будем распространять наработанные решения по парсингу данных и заполнению ими объектов ПланФикса на другие каналы. Первым на очереди стоит разбор ответов на POST-запросы: мы хотим дать возможность разбирать их на такие же инфоблоки и заполнять ими задачи, аналитики и данные контактов. Далее аналогичные возможности должны появиться для задач и комментариев, которые попадают в ПланФикс из других источников — например, мессенджеров, чатов, соцсетей.
А там и новые вызовы подоспеют — есть у эволюции начало, нет у эволюции конца 🙂
Дмитрий, если я правильно все понял, в текущем варианте можно применить несколько правил (старого формата) к одному письму: к примеру найти задачу с совпадением по имени и добавить к ней же действие. Верно?
То. что Вы написали, делается одной операцией – и раньше тоже так же было примерно. Что добавилось в этом плане: появилась возможность найти задачу по значению в каком-то поле, соответствующему извлеченному из письма фрагменту.
>> появилась возможность найти задачу по значению в каком-то поле
Ух ты. Не прошло и сто лет.
Спасибо!
Дмитрий, какую приятную новость вы принесли!
А условие “что делать если задача не найдена” в блоке “Добавить комментарий в существующую задачу” – это ж просто щастье неописуемое!!!
Вы о нём не написали в этом материале специально, чтобы ожидающие этого условия не захлебнулись в брызгах восторга? :)))
PS
А гифка вначале офигенная. Я на ней “залип” на время бОльшее, чем понадобилось потом для чтения материала )
Спасибо, Алексей 🙂
Гифка для тех, кому скучно читать такие новости – пусть хоть глаз порадуется ))
>> А условие «что делать если задача не найдена» в блоке «Добавить комментарий в существующую задачу» — это ж просто щастье неописуемое!!!
Ух ты …
Нужно внимательно посмотреть на новое, а то для Парсинга и просто некоторых действия приходится посылать письма самим себе (в задачах вообще Парсинга нет) с такими костылями … Может хоть что-то упростить получится …
Да, упростить теперь можно многое. Я уже попробовал. И в восторге 🙂
Жалко, конечно, те автосценарии, что нагородил ранее.
Ну да мир праху их…
Чем отличается комментарий от действия?
С терминологией (да и следованием принципам Планфикса) у Планфикса просто беда.
Одни и те же поля в разных местах называются по разному. Путаница местами несусветная …
Нормально просто таблицу распарсить все еще нельзя? Таблица – обычный текст, где столбцы разделены табуляцией или символом | (или иным другим символом …).
Про то, чтобы значения “инфоблоков” брать прямо из заголовка таблицы вообще даже не мечтаем (да и часто там могут быть “объединенные” ячейки)
Или уже можно пытаться (вроде бы появились регулярные выражения и теоретически это может помочь …)
Поддерживаю. Я новичок в Планфиксе и тоже на это обратил внимание. Слишком много вольного использования слов, где, на мой взгляд, должна быть предельная аккуратность и точность.
>> Чем отличается комментарий от действия?
– Изначально по замыслу комментарий это составная часть действия, которое помимо него может содержать файл, аналитику, напоминание и так далее. Но со временем стало ясно, что концепт непривычный и воспринимается тяжело, поэтому мы сейчас планово и постепенно везде переименовываем действия в комментарии.
>> Нормально просто таблицу распарсить все еще нельзя?
– Слишком много вариаций оформления таблиц встречается в реальной практике. Поэтому и были введены инструменты парсинга HTML или через регулярные выражения.
Дмитрий, огромное Вам спасибо за колоссальный труд, который Вы проделываете! На всякие мелочи можно было бы не обращать внимания. И все же, по поводу неточной терминологии. Вы пишите: “мы сейчас планово и постепенно везде переименовываем действия в комментарии”. Но в таком случае уже термин “комментарии” будет перегружен (добавление файлов, аналитики, напоминаний и т.д.). По-моему, вы все-таки идете по пути разделения(где-то мне это уже повстречалось): отдельно употребляете “коментарии” и “действия”.
Сейчас часто “комментарии” и “действия” используются как синонимы, особенно в справке и прочих текстах. Но постепенно будем сводить все к “комментариям”.
Здравствуйте, Дмитрий.
Спасибо за хорошую новость ,мне этого не хватало, теперь все очень логично.
Вот вопрос:,при добавлении аналитики, если у нас уже такая есть создастся дубль?
Здравствуйте, Михаил!
Да, создастся такая же.
Очень крутой апдейт! Не ясно только, можно ли выковырять из входящей почты тему письма и вставить ее в название задачи?
Так ведь по умолчанию тема письма и ведь так становится названием задачи….
Для чего эту тему еще отдельно “выковыривать”?
У меня часто ровно другая проблема – как бы заменить название задачи на что-то иное – либо из письма либо из проекта куда задача упала. И приходится городить такие мутные автосценарии для этого…. просто жуть
Ха ха .. это надо для “общения” с другими тикет системами у которых id в теме. То есть, когда мы им пишем первые, то они отвечают, добавляя в тему какой то там свой [TS-2342323] и нам надо ответить именно с такой темой. В противном случае у них создастся новый тикет.
Посмотрел, не хватает для этого кое-чего. Мы планируем в ближайшее время заняться доработками, которые ждали появления нового интерфейса, одна из них как раз поможет в решении этой задачки. Напишу тут, когда сделаем.
Дмитрий, очень долгожданная новость! Ждал, писал, мучал вашу поддержку… Спасибо!
Хочу добавить письмо действием в существующую задачу, у вас появился механизм поиска подходящий задачи по значению поля. В списке полей вижу только два стандартных поля – Название и Номер – и мои кастомные поля. Так и задумано? Что если я хочу решить свой старый кейс – найти уже существующую задачу где есть отправитель письма (исполнитель или контрагент или еще кто), надо это делать через кастомное поле?
Этот список общий с автоматическими сценариями, специально под правила он не дорабатывался. Системные поля задачи добавляются в него сложнее, чем кастомные – под каждое нужно писать свой собственный кусок кода, который обеспечит его поддержку. Поэтому мы дорабатываем их по запросам. Пообщаюсь с коллегами по поводу добавления в этот список полей с ролями в задаче, если тут нет принципиальных сложностей, поставлю задачу на доработку.
первое что приходит в голову – создать кастомное поле “контакт” и заносить туда отправителя письма при первичном создании задачи. Потом искать задачу по этому кастомному полю, сравнивая его с отправителем нового письма. Будет так работать?
Теоретически да, но на всякий случай лучше проверить.
Дмитрий, в поддержке ответили что не работает так. Очень грустно.
Кажется, функция “найти (активную) задачу где отправитель письма фигурирует в заданной роли и прикрепить письмо комментарием” выглядит весьма естественной и востребованной.
Буду очень рад если реализуете. Спасибо.
И еще возможность брать из входящего письма адрес отправителя и работать с ним как с переменной (в том числе для решения моего кейса) тоже была бы востребованной думаю.
Да, плюсую многократно!
Спрашивал об этом в поддержке уже достаточно давно.
Мне тогда сообщили, что никому кроме меня такое не нужно…
Оказывается нужно 🙂
Дмитрий, как-нибудь можно ускорить реализацию функции, о которой пишет достопочтенный aka_paulo?
Очень страдаю из-за её отсутствия….
Добавление комментария в задачу с отправителем письма в одной из ролей будет реализовано даже без извлечения адреса отправителя в инфоблок. У нас в очереди доработок зафиксирован этот запрос, ждем пока он будет реализован.
Спасибо за проделанную работу!
вопрос по товарам. создаются дубли значений в справочнике или можно будет потом в пф посмотреть сколько всего конкретного товара было продано?
Поля типа “Запись справочника” подбираются из текущих значений справочника. Если нужной записи не находится, создаваться она НЕ будет. Так что ни дублей, ни мусора в принципе от использования правил в справочниках не появится.
В основной операции при создании контакта по шаблону в “поле, по совпадению которого определяется, что контакт существует” есть пункт “Номер контакта”. Вот только я не пойму как этот номер контакта туда передать.
Тут нужно добавить блок с заполнением номера контакта из инфоблока https://pic.planfix.ru/pf/k0/AnkuZb.jpg – он будет работать и для заполнения, и для подбора существующего, если такой уже есть.
Мы доработаем этот момент и сделаем его более очевидным – дополнительный блок с заполнением реквизита будет появляться сразу.
Теперь только заметил, раньше можно было осуществлять подбор задачи, в которую добавить комментарием письмо, по “Название задачи содержит переменную”. Теперь этого нет. Караул!
То есть теперь можно только
Название задачи = Инфоблок,
а не
Название задачи содержит в себе инфоблок.
Или я не так понял?
Это условие работает как “содержит”, так что все должно получиться.
Что-то с форматом “HTML” не получается. Читаю в статье: http://joxi.ru/MAjxzOwTxXkYDm
Пробую, не выходит. Пишу в поддержку, Уважаемая Олеся отвечает:
“Lesya:
Илья, так работать не будет.
Система не видит метки из html”
http://joxi.ru/ZrJZe95TM0nePr
Нашел переписку с Олесей, вижу что вроде бы решается вопрос. Или нет?
Да совместный мозговой штурм помог, как всегда Олеся на высоте. Правда я пока вижу не очень понятную картинку, разницу между исходным html кодом письма и отображением html кода в консоли, но это уже мелочи, разберемся.
У меня схожий запрос с aka_paulo и Алексей Сахоненко.
Один и тот же человек оставляет 2-3-4 заявки с сайта.
Соответственно правило создает нам 2-3-4 задачи у одного и того же контакта. Получается очень не удобно. Хотелось бы сделать так, чтобы создавалась одна задача “Заявка с сайта” и остальные задачи от этого человека падали в нее комментарием.
Идентификатором уникальности был бы номер телефона например.