Всем привет!
Когда необходимо использовать тот или иной инструмент? (по его прямому предназначению)
Когда попросит клиент.
Если клиент конкретно не просит то только Trigger!
Все остальное - бомба замедленного действия.
А что бомбы замедленного действия делают со временем? 
аахах спасибо, с одной стороны понял 
Дмитрий, а можно попросить поподробнее?)
А все очень просто.
Trigger - это код. С кодом работать могут все и его легко отлаживать в случае проблем.
Workflow, Flow, Process Builder - это визуальные инструменты для построения бизнес логики. Работать с ними могут не все, отлаживать тоже хрен пойми как.
В итоге - падает триггер - получаем красивый стектрейс конкретное место где упало.
Падает Workflow, Flow, Process Builder - затуп, непонимание и попытки найти место где же мля упало.
Хорошо если падает, а если просто неправильно работает - удачи в поисках места где неправильно работает! Мышку сотрешь об стол (я про Workflow, Flow, Process Builder )
Это еще не так заметно когда работает один программист, но когда это добро достается в наследство другому программисту - разница между этими элементами сразу чувствуется.
Если надо сделать какое-то мелкое обновление одного поля или ещё что-то очень простое и не участвующее в других бизнес процессах (в цепочке какой), то можно и этими штуками. Но если что-то уже более масштабное, то лучше кодом.
Вообще, сначала начинается там мелочь, и тут чуток. А птм и тут нагромоздить, и вон ещё там отэээээто от прикрутить. "Размазывание" бизнес процессов по разным инструментам только усложнит как саму разработку, так и поддержку. Лучше держать всё в одном месте. И по итогу это одно место - код. Лучше сразу с него начать.
В итоге - падает триггер - получаем красивый стектрейс конкретное место где упало.
Падает Workflow, Flow, Process Builder - затуп, непонимание и попытки найти место где же мля упало.
Хорошо если падает, а если просто неправильно работает - удачи в поисках места где неправильно работает! Мышку сотрешь об стол (я про Workflow, Flow, Process Builder )
Это еще не так заметно когда работает один программист, но когда это добро достается в наследство другому программисту - разница между этими элементами сразу чувствуется.
Круто, спасибо!)
А значит все кликовые фичи вставляют во все модули подряд - штуки для админов и компаний, кто не тянет взять в штат разработчиков?)
Не во всех Editions есть возможность кодить.
Андрей правильно сказал.
Начинается все с малого.
Нет разрабов и клиент сам или друг который знает как кликать в Salesforce начинает потихоньку добавлять кастомную бизнес логику (возможно как вариант Edition куплен сначала слабый, ведь Triggers и Apex в целом появляется с Enterprise). Аппетит приходит во время еды и бизнес логика разрастается по накатанной технологии - клик клик клик. Возможности кликов быстро заканчиваются как и опыт местных разрабов - принимается решение взять в штат квалифицированных супер сертифицированных админов которые начинают накликивать и перекликивать еще виртуознее. В конечном итоге принимается решение перейти на Apex и приглашаются разработчики, которые видят весь этот накликанный ужас пытаются как то дело поддерживать или в лучшем случае переписать (за свой счет, так как клиенты не согласны платить за переделки). Вот так хороший проект и превращается в жуткого монстра.
Это сценарий среднестатистического клиента в SF.
Но лучше когда происходит по другому. Есть опытные люди и проект сразу начинается с Apex. Вот тогда все будет хорошо и проект будет развиваться.
Не всегда верно - если клиент маленький и прямо говорит, что не планирует активно развивать использование сейлсфорса в ближайшей и среднесрочной перспективе, то все эти декларативные штуки оправданы, так как позволят не привлекая разраба(и, соответственно, снижая затраты) быстро поменять бизнес-логику.
Если клиент маленький, но планирует вырасти в среднего или большого, тогда да, лучше использовать Apex, за исключением:
1. Отправки e-mail'ов.
2. Отправки XML/JSON'а на внешний эндпоинт через outbound message.
3. Простейших форм/опросников, которые можно накидать через Flows и которые не планируется часто и серьезно изменять.
В идеале, конечно, предложить клиенту различные варианты и дать ему решать, что делать.
Это ключевые слова. Как клиент пожелает, так и будет! Это закон!!! Никто не оспаривает!
1. Если планируется использовать Email Templates возможно. Но возможности стандартного Email Templates быстро заканчиваются. Видел пару костылей когда брались Email Templates и парсились вручную. Это была жесть. Если что-то другое имеется в виду, интересно обсудить.
2. Это вообще крайне узкая специализация. Не знаю в чем выгода кроме того что это происходит без кода. Особенно интересно знать как реализована обработка ошибок отсылки.
3. Простейшие формы очень быстро эволюционируют в сложные в фантазиях клиентов и лучше сразу делать с запасом на клиентские фантазии чем потом объяснят что "извините, но тут нельзя поменять цвет кнопочки или добавить кастомную валидацию".
Давать клиенту варианты это плохая затея.
Сам этим страдал раньше - писал клиентам километровые письма с вариантами реализации и детальным описанием плюсов и минусов. Опыт показал что это всего лишь попытка снять с себя ответственность и переложить бремя принятия решения со своей технической головы на "тупую" (извините за прямоту) голову клиента.
Клиент это всего лишь бизнесмен. И он не хочет разбираться как что-то работает. Ему важен результат. Это как вы на своей машине приедете на автосервис к мастеру и он начнет предлагать вам варианты как починить вашу машину. Да, с вашей стороны (как клиента) это кажется классным что вы принимаете участие в процессе и все контролируете, но разве вы лучше механика знаете каким способом лучше чинить машину?
Вот как должна развиваться ситуация:
Приходит к вам клиент и просит запилить бизнес процесс при создании Contact.
(идеально) вы говорите ОК и делаете.
(хорошо) вы говорите что запилите с помощью триггера (возможно расскажите о перспективах на будущее, если спросят почему)
(плохо) вы говорите что можно с помощью Триггера, Workflow, Flow, Process Builder и предлагаете клиенту выбрать. Этим вы забиваете голову клиента лишней ненужной информацией и предлагаете сделать выбор основываясь на его 0-м опыте и на авось (или что красивее выглядит).
Dmitry Shnyrev Все верно, сильно зависит от задачи. Где-то хватит e-mail template'а, а где-то нужен VF.
В этом их прелесть - sf для outbound messages в течении 24 часов будет делать попытки повторно отправить outbound message https://help.salesforce.com/articleView?id=workflow_tracking_outbound_message_delivery_status.htm&type=5
Тут ты прав. Тогда нужно самому узнать планы клиента, чтобы сделать правильное решение.
Если клиент прямо говорит делать Workflow, то разработчик берет Workflow и его делает. А если клиент говорит, что должно в итоге получится, то разработчик сам решает, как это сделать.
Разработчика очень часто называют даже тех, кто настраивает всё декларативными инструментами. Я так попадаюсь периодически. Лично я это называю администрированием.
