Событие, послужившее поводом для сегодняшней заметки, способствует растеканию мысли по древу, но я твердо решил держать себя в руках. Поэтому вначале расскажу о сути произошедших изменений и только потом отдамся философствованиям и вглядываниям в далекие дали 🙂
ПланФикс давно умеет создавать задачи из писем. Достаточно прислать письмо на адрес сотрудника, проекта или на специально созданный вами в своем аккаунте виртуальный адрес, и оно станет задачей в ПланФиксе. Правила позволяют управлять созданием таких задач: устанавливать для них правильных исполнителей и участников, задавать нужный проект, дату выполнения и так далее. Они появились в далеком 2011 году и с тех пор постоянно дорабатывались и расширяли свои возможности.
И вот, на границе 2018 и 2019 годов они подошли к черте, за которой их ждал качественный переход на другой уровень. Я уже немного затрагивал эту тему в ноябрьской заметке про наборы действий. А теперь появилась вторая часть необходимого функционала, благодаря которой правила заканчивают этот переход.
Как теперь работают правила обработки почты
Работу правила можно разделить на 3 этапа:
1. Проверяется, подходит ли пришедшее письмо под условия правила. Правило сработает только если все условия будут выполнены:
До этого момента все работает как раньше: результатом срабатывания правила будет создание новой задачи или добавление письма действием в существующую. А вот дальше начинаются изменения.
2. Письмо “разбирается по косточкам”. Из него выделяются нужные элементы и сохраняются во временные переменные:
Вот простой пример, в котором в тексте письма находится имя заказчика и помещается в переменную “ФИО клиента”:
3. Затем создаваемая задача заполняется данными из этих “косточек”-переменных при помощи Набора действий:
Основное отличие этого подхода от используемого ранее: раньше процедура выделения из письма данных и помещения их в поле задачи была цельной, а теперь мы раздробили ее на два независимых этапа. И это очень важное изменение.
Благодаря разделению этапов разбора письма и использования полученных данных, мы получаем две новые возможности:
- Использовать добытые из письма данные для создания не только задач, но и других объектов — в частности, контактов и аналитик. При этом, одна и та же переменная может быть использована несколько раз: например, при создании контакта и для заполнения поля задачи.
- Оперировать полученными данными при помощи всего накопленного (и постоянно добавляющегося) набора операций автоматических сценариев.
Вообще, замена одного “длинного” правила вида “Найти фрагмент в тексте письма и подобрать соответствующий ему проект” на два блока “Положить выделенный фрагмент письма в переменную А” и “Подобрать проект по переменной А” является классическим проявлением тризовского принципа дробления, со всеми вытекающими плюсами.
Но стоп! Я же обещал философствования потом. Всё, не отвлекаюсь, идем дальше.
Новые возможности извлечения текста
Мы не просто выделили извлечение текста в отдельную операцию, но и существенно расширили ее возможности. Например, теперь вы можете оперировать не только текстовыми письмами, но и их HTML-коллегами, которые все чаще встречаются в реальной бизнес-практике:
Это означает, что для выделения фрагмента, содержащего нужные данные, в качестве меток можно использовать окружающие его HTML-теги. А еще для поиска нужного фрагмента в тексте письма теперь можно использовать регулярные выражения:
Сразу скажу: штука это мудреная, и если вы раньше не сталкивались с регулярными выражениями, разобраться будет сложно — лучше сразу зовите на помощь специалистов, которые умеют с ними работать.
И еще одно полезнейшее нововведение — возможность записать в переменную не одно, а все значения, встречающиеся в письме:
Это незаменимая штука при добавлении аналитик. Представьте, что в письме к вам приходит информация о нескольких позициях заказа. Раньше вытащить ее из письма было невозможно, а сейчас — пожалуйста:
1. Находим в письме все фрагменты данных, соответствующие нужному условию, и сохраняем их в переменную:
2. Затем создаем столько строк аналитик, сколько нашлось данных:
Так что возможности по наполнению ПланФикса данными при помощи универсальной интеграции через email с появлением нового механизма разбора писем существенно возрастают.
Резюме “новостной” части
Итак:
- Правила для обработки писем теперь работают по новой схеме: вначале выделяем из текста письма данные и затем отдельным блоком распределяем их по нужным полям.
- “Старые” правила работают без изменений, и так оно и останется. В будущем мы можем ограничить доступность создания правил по старой схеме для новых аккаунтов, но для существующих этого делать нельзя, слишком уж большой багаж работающих бизнес-процессов накоплен с помощью почтовых правил старого образца.
- Старые и новые операции в списке разделены горизонтальной чертой. Это одновременно и символ водораздела, и указание на то, что лучше пользоваться новыми, которые расположены в верхней части списка.
- Новые операции открывают дополнительные возможности и в плане разбора письма, и в плане количества операций, которые можно производить с добытыми из письма данными.
- Помимо задач, при помощи новых операций можно заполнять поля контактов и создавать аналитики.
На этом новости заканчиваются. Дальше идут рассуждения общего плана, которые можно пропустить без особой потери полезности.
Будущее и думы
В заметке про наборы действий в правилах обработки почты я писал, что развивающиеся параллельно наборы операций в автоматических сценариях и почтовых правилах конкурировали друг с другом. В итоге, операции из сценариев “съели” конкурентов и дальше развиваться будут они, а аналогичные операции из “старых” правил для почты останутся лишь в целях обратной совместимости.
Планируя новый блок разбора письма, мы постарались сразу учесть неизбежность аналогичной конкуренции — ведь данные могут попадать в ПланФикс не только по почте. Поэтому делать разбор только для писем было бы неразумно. Так что теперь у нас на него большие планы, как и на связку “разбор – переменные – операции” вцелом. Правила для разбора почты это лишь первый этап, на котором мы отрабатываем работу этого механизма. Затем он постепенно будет распространен на все каналы общения ПланФикса с внешним миром.
Заглянув в будущее, несложно представить возможные сценарии работы этой троицы:
- Клиент переписывается с вами в соцсети или мессенджере. Робот автоматически выделяет из текста его комментариев ссылки на страницы вашего сайта и заносит их в кастомное поле “Интересовался позициями”.
- Пришла заявка от нового клиента. Робот послал POST-запрос с его названием в справочную систему, предоставляющую данные о контрагентах, разобрал ответ и разложил его по нужным полям клиентской карточки.
- Система управления логистической компании, услугами которой вы пользуетесь, прислала в ПланФикс POST-запрос с информацией о доставке вашей посылки получателю. Робот нашел нужный заказ и перевел его в статус “Доставлено клиенту”.
- <место для вашего сценария>.
Так что в недалеком будущем стоит ожидать новостей на этом фронте. Блок разбора научится работать с другими форматами, в частности JSON. Он будет появляться в сценариях, реагирующих на разные события. Его братья по связке — операции в сценариях — тоже будут совершенствоваться, чтобы покрывать все большее количество бизнес-ситуаций. Это происходит уже сейчас: так, например, вместе с новым разбором для почтовых правил, в сценариях появилась возможность добавлять аналитики и без привязки к получению письма. И это лучшая иллюстрация полезности единого подхода, когда операция, созданная для одной цели, автоматически становится доступной для множества других ситуаций, о большинстве из которых мы, создатели ПланФикса, даже не подозреваем.
В общем, впереди нас с вами ждет много интересных событий. И вы тоже можете на них повлиять, присылая нам описания своих бизнес-ситуаций. Работать должны роботы — так давайте вместе их научим 🙂
P.S. На днях выйдет очередной выпуск нашей email-рассылки для энтузиастов, в которую войдет множество новостей о доработках сценариев, формул и новых интеграциях, которые мы добавили в последнее время. Подписаться на эту рассылку вы можете в своей карточке пользователя, вот так.
При работе со значением из переменной очень хотелось бы иметь еще условие отбора. Например в переменную я заношу статус задачи передаваемый мне в письме. Я не знаю какой из множества статусов мне придет. Со всеми статусами надо работать по разному. Хотелось бы записать значение переменной «Статус», например это будет «Решен», а на этапе вставки настроить несколько сценариев:
Переменная Статус – содержит – «решен»
Сделать то-то.
Переменная Статус – содержит – «отклонен»
Сделать то-то.
Переменная Статус – содержит – «оценен»
Сделать то-то.
Переменная Статус – содержит – «закрыт»
Сделать то-то.
Аналогично можно в сценариях, тогда вместо нескольких сценариев (например как в Вашем примере – 4 штуки) можно будет сделать один, но зато сложный.
Это уже несколько действий, вместо настройки в одном интерфейсе.
Сценарий будет работать для всего шаблона в проекте, а мне надо например для определенного отправителя. Ведь у всех партнеров свои биз процессы.
Теоретически можно добавлять дополнительные условия, подобные описанным, но пока мы бы не хотели настолько наворачивать сценарии, так как это существенно ухудшит их читабельность и возможность самому через полгода разобраться, что же я тут накрутил 🙂
Сейчас ситуация решается заполнением поля + сценариями на обработку каждого из возможных значений. То есть, как и предлагает Андрей, если я правильно его понял. То, что обработка разнесена по нескольким сценариям, имеет понятные минусы, но и определенный плюс – легче пройти по цепочке и понять, как она работает и что где пошло не так.
Дмитрий, новость бомбическая 🙂 Спасибо
Я очень прошу немного переключить внимание на внутренний процессинг.
На текущий момент еще к сожалению куча рутины при постановке задач – а это основная задача CRM/ERP.
Очень нужны статусы проекта и привязка к сценариям расстановки задач
https://forum.planfix.ru/viewtopic.php?f=22&t=3740
на форуме не одна тема уже посвящена этому.
Это так, мысли вас подтолкнуть на внутренний мир ПФ заместо внешней связи, а то вы прям туда ушли с головой 🙂 Спасибо!
Спасибо, Дмитрий! На самлм деле, внутреннему миру посвящена основная часть нашей работы, просто ее не всегда видно 🙂 На днях выйдет рассылка для энтузиастов, там как раз много новостей об этих незаметных, но важных вещах. Но до процессов проектов еще не добрались, они впереди, как и многое другое.
Очень хотим разбор JSON в ответе на POST-запрос!
Будет, это ближайший шаг по ветке разбора.
Мы тоже это очень ждем!
Тоже очень ждали тонкой обработки почты. Но получились сплошные обломы:
Облом №1: оказалось, для виртуальных почт. адресов это не работает
Облом №2: если выбрано “Добавить письмо действием в задачу …” – опция разбора “текста” недоступна
Облом №3: Извлекать можно, похоже, только тело письма, но никак не его тему и прочие детали письма
Облом №3: просил больше года назад сделать наконец выбор шаблона, по которому создается задача в случае, если условие “Добавить письмо действием в задачу …” не сработало. По умолчанию стандартный и все.
На самом деле, все только начинается, “сть у революции начало, нет у революции конца” 🙂 Так что вопросы очень кстати.
Облом №1: Тут нужны примеры что именно не работает, потому что все скриншоты к этой заметке я делал именно в правилах для виртуального адреса. Лучше сразу отдельной задачей в Службу поддержки, вдруг мы что-то не учли.
Обломы №2 и 3b: Это еще впереди. Для этого нужно переделать структуру правила, совмещать это с изменением подхода к извлечению данных мы не рискнули, слишком велика вероятность поломать что-то важное и стопорнуть работу большого количества клиентов. Так что отлаживаем работу по уже проведенным измененриям и затем готовимся к следующему этапу.
Облом №3a: Тут очень поможет пример реальной ситуации, в которой нужно извлечь нечто из темы или другого реквизита письма, кроме текста, и потом использовать. Его желательно получить отдельной задачей, потому что вполне возможно, что тут что-то нужно доработать – и нам нужно понимать, что именно. Высасывать примеры из пальца не хочется, поэтому мы ждем именно реальные кейсы, с которыми приходится сталкиваться.
Дмитрий, поддержу по поводу проблемы №1
Тоже не срабатывает сценарий при отправке на виртуальный адрес. Задачу в поддержку отправляла еще до выхода заметки, но мы ее отложили, т.к. функции были еще в тесте. Проверила сейчас – все равно не работает, к сожалению.
А так сама идея просто отличная. Еще бы примеры по регуляркам, т.к. есть несколько стандартов, понять бы, по какому это работает в ПФ 🙂
>> поддержу по поводу проблемы №1
Тоже не срабатывает сценарий при отправке на виртуальный адрес. Задачу в поддержку отправляла еще до выхода заметки, но мы ее отложили, т.к. функции были еще в тесте.
– Значит, надо доставать из отложенных и запускать. Напишите в ней что проблема актуальна, пожалуйста.
>> Еще бы примеры по регуляркам, т.к. есть несколько стандартов, понять бы, по какому это работает в ПФ
– Мне и самому интересно, но вообще самостоятельно поэкспериментировать точно будет быстрее, чем дождаться, пока до этого доберусь я 🙂
+1 к действиям и добавлениям в уже созданной задаче. Пока все новинки работают только в новых задачах, а вся автоматизация (например, обновление полей, раскладка платежей и прочее) – действия в задаче с номером от метки… или подобные.
Не получается добавить аналитику, если это аналитика – справочник!
И вообще, что там со справочниками? Добавьте такие же сценарии для работы со справочниками и мы станем гораздо счастливее:)
>> Не получается добавить аналитику, если это аналитика — справочник!
– Поставьте, пожалуйста, задачу с примером в Службу поддержки.
>> И вообще, что там со справочниками? Добавьте такие же сценарии для работы со справочниками и мы станем гораздо счастливее:)
– Тут тоже помогут примеры, в которых помогли бы сценарии 🙂 Но лучше отдельной задачей. Вообще, сценарии по справочникам пока находятся в зыбком состоянии – то ли будут, то ли нет. И именно по причине малого количества живых кейсов, в которых они реально нужны. Писать функционал “в стол” не хочется, слишком накладно.
Новость божественная.. Еще не тестил, но точно нужная фича.
А вот чего не хватает для полного счастья – это чтобы можно было не только учитывать извлеченный текст сообщения в задаче, но и в справочниках…
Предположим тот же пример с заявкой от клиента, где клиент указал что он хочет.
Робот ищет совпадение с товарной матрицей по какому то признаку, если не находит, то создает эту позицию сразу в матрице и например прилетает задача уже товароведу проверить эту позицию и дополнить сведениями… И к моменту выставление КП менеджером уже будет созданная позиция в матрице..
Ну или пример из нашей практики. Клиент заполняет форму по бронированию за собой определенного проекта. Если записи нет, то система его создает…
Это тоже к вопросу сценариев для справочников, по которым нам не хватает реальных примеров. Будет полезно, если распишите кейс из своей практики чуть более подробно и оформите в виде задачи в Службу поддержки, мы его “подошьем” к общей задаче по сценариям для справочников, это поможет ее продвинуть.
День добрый!
Новость отличная. Есть нюансы.
1. Нужно условие на добавление письма действием в задачу, в которой есть значение в поле. (есть задача,есть поле ID в задаче со значением, пришло письмо со значением в заголовке или содержании письма, нужно добавить письмо действием в эту задачу). Ресурсоемко, но можно сузить задачи, ограничив конкретными полями, или шаблонами задач.
Сейчас реализовано следующим образом – При изменении значении в поле задачи, сценарием меняется заголовок (в него подставляется значение из поля), правило для входящего письма с действием “Добавить письмо действием в задачу, содержащую в названии текст от метки” по которому идентифицируется задача и в неё добавляется комментарий. Минусы – человеческий фактор – изменение названия задачи и т.п., громоздкость.
2. Нет возможности парсинга самого сообщения (при получении письма на виртуальный ящик, если задача не создаётся, а добавляется действие в существующую вышеуказанным (“1”) способом) – есть только несколько вариантов “удалить слово с меткой”, “удалить всё, начиная с метки” и т.п. “Извлечь текст” – нет, соответственно нет возможности дальнейшей работы с текстом.
3. Необходима возможность добавлять “заголовок сообщения действием в задачу”, а не всё письмо.
Здравствуйте, Роман!
Работа над изменением механизма обработки почты продолжается, в том числе они должны решить первые 2 вопроса. А вот с третьим мы пока не сталкивались – для чего нужна такая возможность, можете привести пример из своей практики?
Пример, с которым ежедневно сталкиваемся:
часть заявок обрабатываются сторонними организациями, имеющими собственные платформы для обработки заявок. Таких платформ достаточно много. При проходе заявок по статусам в сторонних сервисах, приходят уведомления на электронную почту. Уведомления вида: в теме письма “Готова к выдаче продукт по заявке №84954690” – к примеру. Текст письма дублирует заголовок и содержит достаточно много служебной информации, которая в принципе никакой смысловой нагрузки не несет. Темы письма достаточно, чтобы процесс в нашей системе перешел дальше по статусам. Также, не плохо, если не подключать данный контакт(как правило письма приходят с одного ящика платформы “no-reply”) к задаче.
Спасибо, ситуация понятная, подумаем над этим.
Ничего не понимаю, как изменить дату завершения задачи, взяв дату из письма, если она в другом формате (гггг.мм.дд)
Все перепробовал. Скрипт “извлечь текст” извлекает дату в другом формате, который не распознается полем типа “дата”. Если извлечь отдельно день, месяц, год, то не получается их соединить воедино, т.к. в поле типа “дата” их внести нет возможности, а если внести в поле типа “строка” свормировав нужный формат даты, то потом в поле типа “дата” нет возможности внести данные из поля типа “строка”. Попробовал такой костыль, как отправка письма с текстом “Дата:дд-мм-гггг” на мыло, а затем обратную пересылку на виртуальный адрес планфикса, чтобы извлечь дату уже в нужном формате, но в этом случае планфикс игнорирует письмо в связи с защитой от зацикливания.
В общем, как я понял, такую элементарную вещь средствами планфикса сделать не удастся, только с использованием сторонних средств. Опровергните, если не прав.
Пишу с телефона и не могу проверить сам – а не поможет ли в этом случае функция ДАТАЗНАЧ()? Она преобразует текст в дату – возможно, получится это использовать. Вот справка https://planfix.ru/docs/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_%D0%94%D0%90%D0%A2%D0%90%D0%97%D0%9D%D0%90%D0%A7
Все это время даже и не знал про функции. Но все-равно не работает. После преобразования функцией показывает “0.0”. В описании нет требуемого формата, который поддерживает функция.
Поставьте, пожалуйста, Службе поддержки задачу с описанием того, что Вы делаете, постараемся помочь разобраться.
Мне очень нужен такой сценарий!
Ставится задача по входящему письму на виртуальный адрес почты ПФ.
В зависимости от дня недели и времени суток в задаче назначается нужный исполнитель.
Пример:
Рабочий режим сотрудников:
Иванов 8:00-12:00 , будни
Петров 12:00-16:00, будни
Если письмо пришло в рабочее время Иванова или Петрова, но они назначаются исполнителями в задаче, иначе Сидоров.
Есть возможность так настроить в Планфиксе?
Сценариями.
По умолчанию исполнитель – Сидоров в задаче.
Для каждого из сотрудников создаем свой сценарий с проверкой рабочего времени сотрудника.
Если он срабатывает, то отстраняем Сидорова, назначаем нужного сотрудника.
А можно чуть подробнее?
Как проверить рабочее время в сценарии?
В чате энтузиастов Вас нет?
Можете мне на почт написать planfix (гав) cutnogood (dot) xyz