столкнулся с проблемой и даже не знаю с чего начать ее описание. так что начну с начала:
сегодня падает в проде тест.
тест работает с тригером на Users.
смотрю в триггер, а там такая шняга:
Flow.Interview.НазваниеКонкретногоFlow flow = new Flow.Interview.НазваниеКонкретногоFlow (мапаcТригерNew);flow.Start();
читаю, понимаю что это запускается Autolaunched Flow куда подаются пришедшие в тригер Юзеры.
смотрю в тот КонкретныйФлоу и вижу, что там какая то логика по вычислению доступных лицензий, небольшая логика в ветвлениях.
как я понимаю, кто-то додумался перенести тригерную логику в Autolaunched Flow...
я немного ф шоке от такого творчества.
Ну и собственно вопрос к вам, дорогие коллеги, что вы думаете по этому поводу? это вообще нормально?
Сама идея не плохая, так как видна логика триггера. Но пока парни из салесфорса не сделают нормальный error handler для flow. Я бы такую штуку не использовал.
неочень, не вижу выгоды вообще использовать это всё... время на изучение функционала который уже есть, или дебаг, или поиск где-что происходит серьезно увеличивается.
у нас в фирме из административной автоматизации используются только workflow и то в основном emailalerts. Вот это действительно удобно + лимиты больше.
на дримфорсе был админ таск (код запрещенно использовать полностью) : сделать чтобы с контакта при апдейте определенного поля создавалось Opportunity связанное с этим контактом и в chatter определенной группе (sales) скидывалось сообщение о успешной продаже со ссылкой на новую Opportunity.
Пока сделал прошло часа 2. Две трети времени потратил чтобы найти нужный функционал. В ProcessBuilder, тем более в workflow нельзя ни создать OppContactRole ни скинуть в чаттер сообщение. В итоге сделал вызов flow через process builder с передачей контакта как параметра. 
удачи тому кто бы искал пару таких решений в реальном проде 
Я не давно столкнулся ассаймент рулами для кейса и очередями назначающимися на кейс и на кейсы еще был заточен триггер.когда начил разбирать эту кашу выяснилось,ассаймент рулез отробатывают после всех триггеров,причем поумолчанию назначается очередь на кейс,даже если ассаймет рулез не имеют не одного действующига правила а просто включен,и происходит это все в стеке после выполнения триггера.Вообщем идея то была переписать все под триггер,потому как не доконца понимал где ждать подвоха в следующий раз если клиент еще чего нибудь захочет.но заказчик на это апрува не дал,поэтому пофиксил кое как и закрыл быстренько.Это я кто му что стандартный функционал SF Для работы с таблицы очень не предсказуем,в плане что будет тратиться больше времени что бы разобраться что да как отробатывает и почему и далеко не факт что не придется переносить и стандартного функционала логику в триггер.
Это вам повезло менеджеры и разработчики вменяемые.Я тоже за такой подход.
Товарищи, вам все еще не кажется что использование всяких фишек плюшек SF добавляет только геморроя?
Я понимаю что Salesforce предоставляет возможности сделать что-то и оставить это максимально гибким для заказчика.
Но что в итоге получается?
Вы мучаетесь чтобы сделать хотелку для заказчика и потом ломаете голову чтобы этот винегред поддерживать, а заказчик все равно туда не лезет или если залезет то сломает всю вашу красивую логику к хренам.
Я понял одно - надо по максимуму прятать от заказчика логику и возможности что-то поменять. Идеальный функционал - пустая страница с одной большой кнопкой, которую заказчик сможет нажать чтобы получить нужный результат.
Workflows, validation rules, approval processes, flows, process builder (или как там его) - я тоже по началу думал что это круто и нужно использовать. Но практика показала - НЕ нужно! Все равно ничего их этого хорошего не получится. Есть Apex+VF - ВСЁ! Делаем все что нужно! Понимаю еще если бы их не было как в других CRM, тогда пришлось бы ломать голову!
так,
подтвердите пожалуйста следующее:
(1) если в такой Autolaunched Flow тригер подает пачку в сотни записей, то Флоу ложится по лимитам, так как там не возможно зарегулировать батч-устойчивое выполнение логики?
(2)когда мы говорим про Autolaunched Flow - это НЕ тот новый Лайтнинг флоу?
спасибо
не в курсе что с лимитами.
Autolaunched Flow - это старый функционал.
validation rules я бы кстати в общую кучу не пихал, всё таки это не элемент автоматизации, и вообще полезная штука. наверно ближе к reqired field. просто вещь о которой надо помнить при разработке кода.
Я бы очень даже включил validation rules в этот список!
Это опять же к тому чтобы не позволять клиенту что-то менять в логике. Уже наверное раз сто раз сталкивался с такой ситуацией - гневный клиент скидывает претензии что него что-то не работает в пакете. Как потом узнается тупо добавили validation rule и пакет тупо на это не рассчитан. Понятное дело что дополнительные проверки в пакете позволяют ускорить процесс нахождения проблемы. НО ВОТ какого хера спрашивается добавлять проверки если не знаешь какой код завязан на скажем этот объект или поле?
Жаль нет такой замечательной штуки как программное отключение этих validation rules. Я считаю что код должен быть важнее этих раскиданных по оргу настроек.
Я тут наверное все-таки уточню - я имею в виду разработку разного рода приложений на базе CRM, а не легкая кастомизация стандартного функционала, когда собственно программисты и не нужны.
Сорри на односторонний взгляд, но я по воле судьбы все свое время на SF занимался и занимаюсь разработкой исключительно кастомного функционала, который никак не коррелируется со стандартным и SF в этом случае используется тупо как платформа-хостинг. В этом случае все эти визуальные штуки абсолютно лишняя хрень!
Причем очень дорогая.
Не разделяю такой выбор заказчиков.
Абсолютно точно! Но заказчик есть заказчик. Обычно заказчики уже приходят с проплаченным оргом или уже работающим проектом - тут выбирать не приходится. Но если ко мне обращаются за советом еще до покупки я так и говорю "только не Salesforce". Понимаю что не патриотично, но совесть не позволяет сказать по другому.
Но с другой стороны еще не известно что в итоге окажется дешевле.
Одно дело когда я любой сложности функционал могу сделать и выложить на тот же VPS за 10$ и никакие лимиты мне не страшны (сравнимые относительно SF лимиты). А заказчику то как поступать - надо найти программиста, админа для сервера, и получить черный ящик еще не известно как работающий. Salesforce хотя бы снимает такие вопросы как поддержка инфраструктуры, обеспечение безопасности, настройки в шаговой доступности (даже школьник разберется в структуре приложения имея один браузер и мышку).
Так что тут еще задуматься стоит 
где дешевле.
Autolaunched flows действительно страдают от отсутствия дебага.
Плохой или хороший это инструмент зависит от контекста и общей архитектуры - если вся логика транзакции ворочается в апексе, а какой-то флажок ставится во флоу\воркфлоу - то это добавит только геморроя в отладке и уж лучше все вынести в код.
Чисто "технические" задачи лучше делать в коде, если операция имеет "бизнес" смысл (отправка уведомлений при наступлении условий, смена статуса при других условиях, то имеет смысл вынести это в декларативные функции форса. Опять таки, главное сохранять малую зависимость с другой логикой. Ну и диалог с заказчиком никто не отменял, на то мы и специалисты чтобы помочь им сориентироваться в доступных опциях по решению вопроса и плюсах\минусах каждого из них. Нам только разработать, а 80 процентов затрат на софт чаще приходится на его поддержку, нежели первоначальную разработку.
