Когда использовать - Workflow, Flow, Process Builder, Trigger

Когда использовать - Workflow, Flow, Process Builder, Trigger

Всем привет!
Когда необходимо использовать тот или иной инструмент? (по его прямому предназначению)

Когда попросит клиент.
Если клиент конкретно не просит то только Trigger!
Все остальное - бомба замедленного действия.
А что бомбы замедленного действия делают со временем?

Dmitry Shnyrev
Когда попросит клиент.
Если клиент конкретно не просит то только Trigger!
Все остальное - бомба замедленного действия.
А что бомбы замедленного действия делают со временем?

аахах спасибо, с одной стороны понял
Дмитрий, а можно попросить поподробнее?)

А все очень просто.
Trigger - это код. С кодом работать могут все и его легко отлаживать в случае проблем.
Workflow, Flow, Process Builder - это визуальные инструменты для построения бизнес логики. Работать с ними могут не все, отлаживать тоже хрен пойми как.

В итоге - падает триггер - получаем красивый стектрейс конкретное место где упало.
Падает Workflow, Flow, Process Builder - затуп, непонимание и попытки найти место где же мля упало.

Хорошо если падает, а если просто неправильно работает - удачи в поисках места где неправильно работает! Мышку сотрешь об стол (я про Workflow, Flow, Process Builder )

Это еще не так заметно когда работает один программист, но когда это добро достается в наследство другому программисту - разница между этими элементами сразу чувствуется.

Если надо сделать какое-то мелкое обновление одного поля или ещё что-то очень простое и не участвующее в других бизнес процессах (в цепочке какой), то можно и этими штуками. Но если что-то уже более масштабное, то лучше кодом.
Вообще, сначала начинается там мелочь, и тут чуток. А птм и тут нагромоздить, и вон ещё там отэээээто от прикрутить. "Размазывание" бизнес процессов по разным инструментам только усложнит как саму разработку, так и поддержку. Лучше держать всё в одном месте. И по итогу это одно место - код. Лучше сразу с него начать.

Dmitry Shnyrev
А все очень просто.
Trigger - это код. С кодом работать могут все и его легко отлаживать в случае проблем.
Workflow, Flow, Process Builder - это визуальные инструменты для построения бизнес логики. Работать с ними могут не все, отлаживать тоже хрен пойми как.

В итоге - падает триггер - получаем красивый стектрейс конкретное место где упало.
Падает Workflow, Flow, Process Builder - затуп, непонимание и попытки найти место где же мля упало.

Хорошо если падает, а если просто неправильно работает - удачи в поисках места где неправильно работает! Мышку сотрешь об стол (я про Workflow, Flow, Process Builder )

Это еще не так заметно когда работает один программист, но когда это добро достается в наследство другому программисту - разница между этими элементами сразу чувствуется.

Круто, спасибо!)
А значит все кликовые фичи вставляют во все модули подряд - штуки для админов и компаний, кто не тянет взять в штат разработчиков?)

Ian Skidkov
А значит все кликовые фичи вставляют во все модули подряд - штуки для админов и компаний, кто не тянет взять в штат разработчиков?)

Не во всех Editions есть возможность кодить.

Андрей правильно сказал.
Начинается все с малого.
Нет разрабов и клиент сам или друг который знает как кликать в Salesforce начинает потихоньку добавлять кастомную бизнес логику (возможно как вариант Edition куплен сначала слабый, ведь Triggers и Apex в целом появляется с Enterprise). Аппетит приходит во время еды и бизнес логика разрастается по накатанной технологии - клик клик клик. Возможности кликов быстро заканчиваются как и опыт местных разрабов - принимается решение взять в штат квалифицированных супер сертифицированных админов которые начинают накликивать и перекликивать еще виртуознее. В конечном итоге принимается решение перейти на Apex и приглашаются разработчики, которые видят весь этот накликанный ужас пытаются как то дело поддерживать или в лучшем случае переписать (за свой счет, так как клиенты не согласны платить за переделки). Вот так хороший проект и превращается в жуткого монстра.
Это сценарий среднестатистического клиента в SF.
Но лучше когда происходит по другому. Есть опытные люди и проект сразу начинается с Apex. Вот тогда все будет хорошо и проект будет развиваться.

Dmitry Shnyrev
Если клиент конкретно не просит то только Trigger!

Andrii Muzychuk
Если надо сделать какое-то мелкое обновление одного поля или ещё что-то очень простое и не участвующее в других бизнес процессах (в цепочке какой), то можно и этими штуками.

Не всегда верно - если клиент маленький и прямо говорит, что не планирует активно развивать использование сейлсфорса в ближайшей и среднесрочной перспективе, то все эти декларативные штуки оправданы, так как позволят не привлекая разраба(и, соответственно, снижая затраты) быстро поменять бизнес-логику.
Если клиент маленький, но планирует вырасти в среднего или большого, тогда да, лучше использовать Apex, за исключением:
1. Отправки e-mail'ов.
2. Отправки XML/JSON'а на внешний эндпоинт через outbound message.
3. Простейших форм/опросников, которые можно накидать через Flows и которые не планируется часто и серьезно изменять.
В идеале, конечно, предложить клиенту различные варианты и дать ему решать, что делать.

EvAzi
если клиент

Это ключевые слова. Как клиент пожелает, так и будет! Это закон!!! Никто не оспаривает!

EvAzi
за исключением:

1. Если планируется использовать Email Templates возможно. Но возможности стандартного Email Templates быстро заканчиваются. Видел пару костылей когда брались Email Templates и парсились вручную. Это была жесть. Если что-то другое имеется в виду, интересно обсудить.
2. Это вообще крайне узкая специализация. Не знаю в чем выгода кроме того что это происходит без кода. Особенно интересно знать как реализована обработка ошибок отсылки.
3. Простейшие формы очень быстро эволюционируют в сложные в фантазиях клиентов и лучше сразу делать с запасом на клиентские фантазии чем потом объяснят что "извините, но тут нельзя поменять цвет кнопочки или добавить кастомную валидацию".

EvAzi
В идеале, конечно, предложить клиенту различные варианты и дать ему решать, что делать.

Давать клиенту варианты это плохая затея.
Сам этим страдал раньше - писал клиентам километровые письма с вариантами реализации и детальным описанием плюсов и минусов. Опыт показал что это всего лишь попытка снять с себя ответственность и переложить бремя принятия решения со своей технической головы на "тупую" (извините за прямоту) голову клиента.

Клиент это всего лишь бизнесмен. И он не хочет разбираться как что-то работает. Ему важен результат. Это как вы на своей машине приедете на автосервис к мастеру и он начнет предлагать вам варианты как починить вашу машину. Да, с вашей стороны (как клиента) это кажется классным что вы принимаете участие в процессе и все контролируете, но разве вы лучше механика знаете каким способом лучше чинить машину?

Вот как должна развиваться ситуация:
Приходит к вам клиент и просит запилить бизнес процесс при создании Contact.
(идеально) вы говорите ОК и делаете.
(хорошо) вы говорите что запилите с помощью триггера (возможно расскажите о перспективах на будущее, если спросят почему)
(плохо) вы говорите что можно с помощью Триггера, Workflow, Flow, Process Builder и предлагаете клиенту выбрать. Этим вы забиваете голову клиента лишней ненужной информацией и предлагаете сделать выбор основываясь на его 0-м опыте и на авось (или что красивее выглядит).

Dmitry Shnyrev Все верно, сильно зависит от задачи. Где-то хватит e-mail template'а, а где-то нужен VF.

Dmitry Shnyrev
2. Это вообще крайне узкая специализация. Не знаю в чем выгода кроме того что это происходит без кода. Особенно интересно знать как реализована обработка ошибок отсылки.

В этом их прелесть - sf для outbound messages в течении 24 часов будет делать попытки повторно отправить outbound message https://help.salesforce.com/articleView?id=workflow_tracking_outbound_message_delivery_status.htm&type=5
Dmitry Shnyrev
Давать клиенту варианты это плохая затея.

Тут ты прав. Тогда нужно самому узнать планы клиента, чтобы сделать правильное решение.

Если клиент прямо говорит делать Workflow, то разработчик берет Workflow и его делает. А если клиент говорит, что должно в итоге получится, то разработчик сам решает, как это сделать.
Разработчика очень часто называют даже тех, кто настраивает всё декларативными инструментами. Я так попадаюсь периодически. Лично я это называю администрированием.

Interesting information? Help us, post link to social media..