Реализация Double Opt-in

Для начала бы всем присутствующим знать, что такое «Double Opt-In». Если речь об этом:

То это довольно похоже на стандартные механизмы раздела кампаний в bpm'online marketing с добавлениями из лендинга и триггерными рассылками:

Естественно, потребуются те самые лицензии на активные контакты.

Без них можно только отправлять почту прямо из системы по SMTP в рамках логики БП, что мало масштабируемо и нагружает систему.

Зверев Александр пишет:

То это довольно похоже на стандартные механизмы раздела кампаний в bpm'online marketing с добавлениями из лендинга и триггерными рассылками:

Да, очень похоже. Но пока непонятны некоторые моменты:

- как отлавливать завершение кампании Double Opt-In, чтобы в карточке контакта уже отметить, что он прошёл подписку до конца?

- как унифицировать это решение, чтобы не копировать в каждом landing page, где контакт может подписаться? 

Для этого служит элемент «Выход из кампании». Там отмечают не в карточке, но на детали:

Всем контактам, которые по переходу или согласно настроенным условиям группы попали на этот шаг, на вкладке [Аудитория] в колонке [Текущий шаг] будет установлено значение “Достигли цели”

Движок кампаний поддерживает ветвления, можно попробовать добавить в одной кампании несколько разных элементов «Добавить из лендинга».

Возникли ещё 2 вопроса:



1. Минимальный период запуска кампании - 15 минут, что слишком долго, чтобы выслать клиенту письмо с подтверждением подписки (большинство не дождётся, и не ответит)

2. Процесс, кажется, не отлавливает изменения в детали Campaign participant. По крайней мере, ни разу за день процессы (реальный и тестовый) не сработали, хотя, участники добавлялись и даже дошли до цели:

 

Процесс не запустится по событию на объекте, если добавление или изменение делается не при помощи механизмов EntitySchemaQuery, а посредством классов Insert/Update или напрямую в базе. Вероятно, для этой детали происходит именно так.

Зверев Александр пишет:

Процесс не запустится по событию на объекте, если добавление или изменение делается не при помощи механизмов EntitySchemaQuery, а посредством классов Insert/Update или напрямую в базе. Вероятно, для этой детали происходит именно так.

Интересно, а как тогда люди на bpm'online реализуют такой механизм Double Opt-In? 

Если логика простая — можно на триггере в базе. Или по таймеру проверять новые записи, которые ещё не обработаны. Или из того же триггера запустить через веб-сервис БП с Id нужной записи в параметре. Или найти то место в коде, где произошло добавление на деталь в обход ESQ (если дело действительно в этом) и добавить вызов нужной логики.