Ну что ж, погуглил я фразу Salesforce Flow Best Practices и первой выпадает вот эта статья:
https://admin.salesforce.com/blog/2021/t ... tandardsчто выглядит справедливо, так как автор участвовал в разработке Flow
и вот три вещи оттуда:
(1) Статья начинается с фразы "
There’s no way around it: Salesforce Flow is the automation tool of the future", что можно вольно перевести "
Вам отвертеться: Salesforce Flow - это будущее". И здесь можно справедливо возразить: "
Ну а что ты рассчитывал услышать от самого автора тула?", да вот беда: идея того что Low Code / No Code - это наше будущее (и настоящее), уже попала в головы маркетологов, и они убедились, что этот подход очень нравится клиентам. И теперь буквально каждая презентация для клиентов начинается и заканчивается фразой Low Code / No Code Platform. В такой ситуации нет никакой надежды, что это временный хайп, что можно отвертеться или отсидеться в сторонке.
(2) Лимиты - оказывается они есть, все те же старые знакомые, со всеми вытекающими. Хуже того, там есть какие то специфичные и просто леденящие душу любого разработчика лимиты вроде "executed element limit", который работает даже на вложенные в цикл элементы и счет идет на каждую итерацию (!), что делает невозможной итерацию мало-мальски больших массивов. И этот момент (счет элементов в цикле) вроде как отменили уже, но сама мысль, что во Flow могут быть вот такие засады - это пугает. И как решение сложных ситуаций с лимитами, автор предлагает вызывать Apex code... Вот такой вот любопытный No Code :)
(3) Но больше всего мне было интересно, как в целом на архитектурном уровне организовать все эти Flow, на что автор отвечает: "
We’re still very much in the ‘wild wild west’ phase of record-triggered flows as architects and admins figure out the best way to incorporate them into their systems", что можно вольно перевести как "
да *** его знает, главное - чтоб работало". И даже приводит пример, что для централизованной "оркестрации" можно использовать Apex trigger handler, который вызывает эти Flow.
Вот такое вот "новое будущее", которое нужно вызывать из все того же старого trigger handler :)
)? Такая гибкость кода в сочетании со стандартным UI это стоит многого. Так зачем отказываться от такого дара как код в пользу LCNC?????????????????????
