Жизнь в Low Code / No Code реальности: плюсы и минусы

[quote="Den Brown"]Для начала приведу плюс: Flow имеют функционал версии и их историю, это очень удобно, и чувствуешь себя спокойнее[/quote] не совсем доволен исполнением. Этой фишки. Особенно если flow интегрированно в другой процесс. В этом случае пока отладишь flow нужно сделать версий 20

А так да инструмент удобный и относительно легко кастомизируется род нужны каждого клиента

Инструмент удобный, но постоянно встречаются проблемы, когда входят в пакет. Плюс медленный.

На всех проектах где сталкивался с No Code ничего кроме проблем не наблюдалось. Функционал они покрывали минимальный, зато косяков добавляли тонну. Особенно по падающим лимитам. Сам не использую, но клиенты любят эти flow поковырять. А потом сидишь и ломаешь голову почему тесты в сандбоксе работают, а на проде падают. Поэтому я за 100% Code-Only подход, а тек кто пробует все эти новомодные фишки линейкой по пальцам. :smiley:

[quote="Dmitry Shnyrev"]Поэтому я за 100% Code-Only подход[/quote]

Я исключительно про Screen Flow. К остальному пока особенно нет доверия

[quote="Dmitry Shnyrev"]На всех проектах где сталкивался с No Code ничего кроме проблем не наблюдалось.[/quote]

когда это было? какие проекты? если что-то вроде приложений-пакетов, то там конечно все на апексе


[quote="Dmitry Shnyrev"]Особенно по падающим лимитам[/quote]

у меня пруфов нет, но все же такое ощущение, что по Flow уже многое оптимизировано behind scene, так что и самая дурацкая логика работает. у нас triggered Flow (сконфигурированные джунами) выживают даже при дата-лоаде.

[quote="wilder"]Я исключительно про Screen Flow[/quote]

может и на triggered Flow уже стоит посмотреть внимательнее

[quote="Den Brown"]может и на triggered Flow уже стоит посмотреть внимательнее[/quote]
Может. Есть такой проект refactoring называется:)

[quote="Den Brown"]когда это было? какие проекты? если что-то вроде приложений-пакетов, то там конечно все на апексе[/quote]
Естественно я про "большие" проекты где тонны кода и где куча различной калькуляции, где одна DML операция может тригерить десятки триггеров и асинхронных процессов. И когда к этой магии на apex еще начинают приплетаться какие-то "неизвестные" flow которые клиент сам придумал, то тут ничего хорошего не жди. 
То что клиент на стандартном пустом орге играет Flow то пусть играет. Все равно ничего сложнее аналога простейшего триггера типа "посчитать и заполнить поле" не сделает. И смысл такому клиенту нанимать дорогого разраба?

Я может плохо пытаюсь донести свою мысль, но основная проблема No Code подхода в том что это инструмент "одного орга". Когда у тебя прод и [b]один[/b] человек которые занимается его [b]настройкой[/b]. А если у тебя команда разрабочиков, сандбоксы для разработки, репозиторий,  CI/CD? Где тут место No Code?

Тут на самом деле палка о двух концах.  Есть один проект. Мы поставили своей продукт, кастомзтровали его под клиента. А потом клиент взял команду из Мексики и давай кастомизировать все и все. Почти все написано на апексе и куче Financial Force пакетов. Казалось бы все апекс, но я когда получаю баг оттуда, то у меня глаз начинает дергаться. Потому что только  для того что бы понять в чем проблема, может уйти день в отладке. Это тот самый клиент у которого установка пакета обычно занимает от 4 часов. Хотя обычно это берет минут 10-20.

В общем я за то, что решения были разные, тогда хотя бы можно выбирать:) А то в некоторых случаях и выбора нет:)

[quote="wilder"]А потом клиент взял команду из Мексики и давай кастомизировать все и все. Почти все написано на апексе и куче Financial Force пакетов. Казалось бы все апекс, но я когда получаю баг оттуда, то у меня глаз начинает дергаться.[/quote]
Так а разве не работает принцип "кто последний тот и папа"? Пусть мексиканцы и фигсят то что накастомизировали? Хотя тут наверное больше вопрос $$$ :smiley:

[quote="wilder"]В общем я за то, что решения были разные, тогда хотя бы можно выбирать:) А то в некоторых случаях и выбора нет:)[/quote]
Но собственно пример я не совсем понял. Пришли челы нахуевертили тонну апекса который сложно дебажить. А если бы они накликали тоже самое на Flow было бы легче??? Я помню пару моментов, но тут скорее сказывается недостаток опыта при работе с Flow когда у меня вообще не получалось что-то отдебажить и понять почему Flow падает на тестах при деплое. Получалось залить релиз только если деактивировать Flows. А потом через какое-то время я забыл активировать Flows назад и оказывается что они не особо были нужны - никто про них и не вспомнил. Это последний печальный опыт работы с No Code который лишний раз укрепил мое мнение что No Code зло. 

[quote="Dmitry Shnyrev"]Так а разве не работает принцип "кто последний тот и папа"? Пусть мексиканцы и фигсят то что накастомизировали? Хотя тут наверное больше вопрос $$$ [/quote]

Конечно работает, но сначала нужно доказать что это не ты...

[quote="Dmitry Shnyrev"]мое мнение что No Code зло[/quote]
В общем такого мое мнение. Понимаю что серьезных аргументов у меня нет, а есть чисто субьективные впечатления. Но уверен что есть моменты когда No Code имеет право на жизнь :party:

Уже стоит ощущение, что например делать кастомную логику на апексе - это bad practice, a best practice - это все запилить во Флоу (за исключением самых тяжелых случаев)

и не забывайте что SF активно раскручивает свой OmniStudio

так что надежда, что это все временное поветрие, может и не оправдаться, и эти все LC/NC тулы придется принять и обнять как родных

[quote="Den Brown"]Уже стоит ощущение, что например делать кастомную логику на апексе - это bad practice, a best practice - это все запилить во Флоу (за исключением самых тяжелых случаев). 
[/quote]

И кстати клиент будет считать это совершенно верным

[quote="Den Brown"]Уже стоит ощущение, что например делать кастомную логику на апексе - это bad practice, a best practice - это все запилить во Флоу (за исключением самых тяжелых случаев)[/quote]
И ты как программист считаешь что это верно? Что код который читается, правится за секунду, покрывается тестами, дебажится, является bad practice по сравнению с кучей окошечек, менюшечек и прочей UI дряни. 

Я точно не сплю?

Вот к примеру, давайте простой пример задачи возьмем. Скажем надо показать погоду (или курсы валют) взятую по API из какого-то стороннего сайта. Как вы это на Flow сделаете? Я нуб по Flow, я не представляю. Проясните. Или скажем мне надо сгенерить PDF с какой-то инфой, ну или массовый пересчет каких-то значений каждый день (батч на apex).

Кстати идея! Давай те предлагать задачи и предлагать варианты решения на No Code. Я думаю это будет это будет крайне полезный вариант ведения беседы по этой теме. 

Лично я в плане Flow сталкивался(видел) с задачами типа "на create/update какого-то объекта заполнить какие-то поля по условиям". Это простой триггер. Такую задачу для Flow я еще представляю. Давайте накидывать более тяжелые задачи и пробовать решить их на Flow. 

[quote="Den Brown"]И кстати клиент будет считать это совершенно верным[/quote]
Мой текущий клиент кстати тоже считает что No Code лучше поэтому сам и ковыряется в нем периодически чем доставляет мне проблемы. Он пару раз пробовал настоять на том чтобы я изучил эту тему глубже чтобы отказаться от кода и погрузиться в мир флов. Но я максимально стараюсь не поддаваться. Последний раз мы касались этой темы когда потратили на созвоне 2 часа пробуя настроить простейший флоу, а у меня сдали нервы и я прямо во время разговора в бэграунде запилил апекс триггер, прикрутил тест и залил на прод и сказал что уже все готово и нет смысла ковырять дальше этот flow.

[quote="Dmitry Shnyrev"]Я точно не сплю?[/quote]

точно не спишь, особенно:

если клиент считает, что Flow is the best practice, т.к. во время выбора платформы они купились на СФ разговоры о LC/NC faster to market approach,

если старший архитект (кто уже 20 лет не писал никакой код, но точно следует всем рекомендациям СФ) тоже считает что нужно следовать рекомендациям и best practice

удачи с ними спорить!

[quote="Den Brown"]что нужно следовать рекомендациям и best practice[/quote]

Всякие NoCode тулы по любому должны продвигаться. На их разработку потратили же деньги. Это какой-то продукт который надо продать. Но мы то с вами взрослые люди и не должны вестись на всякий желтый пиар. У Flow есть своя ниша но увы за пределами серьезной SF разработки.

Для примера задач может завести отдельную тему? А как картинки добавлять?

[quote="Dmitry Shnyrev"]Всякие NoCode тулы по любому должны продвигаться. На их разработку потратили же деньги. Это какой-то продукт который надо продать. Но мы то с вами взрослые люди и не должны вестись на всякий желтый пиар. У Flow есть своя ниша но увы за пределами серьезной SF разработки.[/quote]

все так и есть. и отнекиваться от этих тулов больше не представляется возможным, так как можно прослыть "[i]старым отсталым ретроградом[/i]". Люди помнят как VFP была заменена на Aura, затем на LWC. И этот процесс был абсолютно неизбежным, т.к. отражал "эволюционное" развитие технологии. И такие же ожидания люди прикладывают на переход на LC/NC, хотя здесь перемены более революционные, чем эволюционные, и не все так однозначно

[quote="wilder"]А как картинки добавлять?[/quote]
Загрузить на какое-то хранилище картинок которое дает тебе прямую ссылку и использовать иконку картинки в меню редактора выше. Но нужна именно прямая ссылка так как она подставляется в тег <img>

[img]https://mixnews.lv/wp-content/uploads/2023/06/25/2023-06-25-mixnews-mycollages-30.jpg[/img]

[img]https://i.ibb.co/Kwjq1VF/image.png[/img]

Я использую этот сервис
https://ru.imgbb.com/

Но там чтобы прямую ссылку получить надо немного покопаться - после загрузки надо открыть картинку в полном размере и скопировать адрес изображения через контекстное меню.

типа такого 
https://i.ibb.co/Kwjq1VF/image.png

Влезу с вопросом -  а лимиты которые в этих флоу всегда раньше падали уже пофиксили как-то?
Ведь раньше каждый флоу запускался отдельно, и если ты писал триггер на флоу, и таких было несколько чтук, это значило что в целом платформа просто несколько раз прокручивала одни и те же записи в цикле(если такой был внутри флоу), а при вставке кучи записей одновременно. Раньше еще был прикол, что флоу запускались в разнобой, сейчас вроде уже можно очередность выставлять,что очень хорошо

Но я в целом к флоу отношусь только как к запасному аэродрому, на нашем проекте много разных флоу, но за них отвечают админы, в них делается отправка email, или например time based действия. Есть еще флоу для отправки к нужному сапорт агенту людей, которые пришли в чат за помощью. И все эти части у меня нет ни малейшего желания поддерживать в апекс коде, поэтому флоу тут идеально вписывается, а писать на флоу калькуляции чего либо - ну нет, спасибо)

Скрин флоу тоже хорошая и интересная тема, когда нужно вывести что-то простое на странице и не тратить на это сутки

[quote="Maxim Elets"]сейчас вроде уже можно очередность выставлять,что очень хорошо[/quote]
Если я правильно помню вроде сортировка по имени дает очередность запуска

[quote="Maxim Elets"]Влезу с вопросом - а лимиты которые в этих флоу всегда раньше падали уже пофиксили как-то?[/quote]

возможно, и даже вероятно. Никаких пруфов у меня нет, но в моем понимании СФ делает все возможное, чтобы самый тупой Flow код-алгоритм работал

но это все надо тестить и гуглить

я вообще бы начал с изучения best practice about Flow, я помню были best practice about Process Builder, но до них как-то все не доходило. а вот теперь придется

Вот пример. Есть related list из него по кнопке открывается flow. Во flow показываются 3 компонента

[img]https://i.ibb.co/HGTZ5zY/Untitled.png[/img]

Ну что ж, погуглил я фразу Salesforce Flow Best Practices и первой выпадает вот эта статья:

https://admin.salesforce.com/blog/2021/the-ultimate-guide-to-flow-best-practices-and-standards

что выглядит справедливо, так как автор участвовал в разработке Flow

и вот три вещи оттуда:

(1) Статья начинается с фразы "[i]There’s no way around it: Salesforce Flow is the automation tool of the future[/i]", что можно вольно перевести "[i]Вам отвертеться: Salesforce Flow - это будущее[/i]". И здесь можно справедливо возразить: "[i]Ну а что ты рассчитывал услышать от самого автора тула?[/i]", да вот беда: идея того что Low Code / No Code - это наше будущее (и настоящее), уже попала в головы маркетологов, и они убедились, что этот подход очень нравится клиентам. И теперь буквально каждая презентация для клиентов начинается и заканчивается фразой Low Code / No Code Platform. В такой ситуации нет никакой надежды, что это временный хайп, что можно отвертеться или отсидеться в сторонке.

(2) Лимиты - оказывается они есть, все те же старые знакомые, со всеми вытекающими. Хуже того, там есть какие то специфичные и просто леденящие душу любого разработчика лимиты вроде "executed element limit", который работает даже на вложенные в цикл элементы и счет идет на каждую итерацию (!), что делает невозможной итерацию мало-мальски больших массивов. И этот момент (счет элементов в цикле) вроде как отменили уже, но сама мысль, что во Flow могут быть вот такие засады - это пугает. И как решение сложных ситуаций с лимитами, автор предлагает вызывать Apex code... Вот такой вот любопытный No Code :)

(3) Но больше всего мне было интересно, как в целом на архитектурном уровне организовать все эти Flow, на что автор отвечает: "[i]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[/i]", что можно вольно перевести как "[i]да *** его знает, главное - чтоб работало[/i]".  И даже приводит пример, что для централизованной "оркестрации" можно использовать Apex trigger handler, который вызывает эти Flow.

Вот такое вот "новое будущее", которое нужно вызывать из все того же старого trigger handler :)

[quote="Den Brown"]Ну что ж, погуглил я фразу Salesforce Flow Best Practices и первой выпадает вот эта статья:

https://admin.salesforce.com/blog/2021/the-ultimate-guide-to-flow-best-practices-and-standards

что выглядит справедливо, так как автор участвовал в разработке Flow

и вот три вещи оттуда:

(1) Статья начинается с фразы "[i]There’s no way around it: Salesforce Flow is the automation tool of the future[/i]", что можно вольно перевести "[i]Вам отвертеться: Salesforce Flow - это будущее[/i]". И здесь можно справедливо возразить: "[i]Ну а что ты рассчитывал услышать от самого автора тула?[/i]", да вот беда: идея того что Low Code / No Code - это наше будущее (и настоящее), уже попала в головы маркетологов, и они убедились, что этот подход очень нравится клиентам. И теперь буквально каждая презентация для клиентов начинается и заканчивается фразой Low Code / No Code Platform. В такой ситуации нет никакой надежды, что это временный хайп, что можно отвертеться или отсидеться в сторонке.

(2) Лимиты - оказывается они есть, все те же старые знакомые, со всеми вытекающими. Хуже того, там есть какие то специфичные и просто леденящие душу любого разработчика лимиты вроде "executed element limit", который работает даже на вложенные в цикл элементы и счет идет на каждую итерацию (!), что делает невозможной итерацию мало-мальски больших массивов. И этот момент (счет элементов в цикле) вроде как отменили уже, но сама мысль, что во Flow могут быть вот такие засады - это пугает. И как решение сложных ситуаций с лимитами, автор предлагает вызывать Apex code... Вот такой вот любопытный No Code :)

(3) Но больше всего мне было интересно, как в целом на архитектурном уровне организовать все эти Flow, на что автор отвечает: "[i]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[/i]", что можно вольно перевести как "[i]да *** его знает, главное - чтоб работало[/i]".  И даже приводит пример, что для централизованной "оркестрации" можно использовать Apex trigger handler, который вызывает эти Flow.

Вот такое вот "новое будущее", которое нужно вызывать из все того же старого trigger handler :)[/quote]

Это довольно древняя статья, но от apex даже спустя 2 года после выхода все равно никуда не деться :)
А в целом лимиты я погуглил: на элементы лимит был 2000, с 57 api версии их убрали совсем  :party::party:
То есть раньше если был цикл в флоу то каждый IF внутри цикла считался как элемент и значит если у тебя там было if else - это 3 элемента минимум то есть флоу мог пробежаться по 600 записям примерно, а потом он счастливо умирал :so-sad:

Вот здесь хорошо объяснены основные недостатки LCNC approach:


linkedin.com/pulse/why-low-code-no-code-just-doesnt-cut-software-development-

Вот кстати интересный ресурс попался на глаза - выгляди как набор инструкций по NoCode в одном месте

[url=https://help.salesforce.com/s/articleView?id=sf.extend_click_intro.htm&type=5]Extend Salesforce with Clicks, Not Code[/url]

[quote="Dmitry Shnyrev"]набор инструкций по NoCode в одном месте
[/quote]

ну это просто перечень для конфигурирования и кастомизация орга.

должна же быть какая-то грань между конфигурированием, дроп-энд-дропом и LCNC. 

LCNC -это все же программирование, декларативное, но программирование.

цель данной темы было не обсуждение того, почему мы любим или не любим, хотим или не хотим весь этот LCNC

LCNC уже здесь, и одно дело как с ним самому работать, а другое дело - как с ним вообще жить в одном орге.

и проблема в том, что в реальности это будешь НЕ ТЫ, кто будет делать все эти флоу в большом сложном орге, а другие люди. и в лучших традициях LCNC рекламы - "да любой с этим может работать" - это будут именно люди с таким уровнем подготовки. с околонулевым уровнем подготовки, понимания и ответсвенности, которые могут действовать так, как будто there is no tomorrow. а так как на такой уровне всегда большая текучка кадров, то для такого человека действительно нет нужды заботится о последствиях действий, так как он нашел уже новую работу

и с помощью инструментов LCNC все эти люди теперь могут делать довольно много, и прям проде. как с этим жить и выжить, вот в чем вопрос

[quote="Den Brown"]как с этим жить и выжить, вот в чем вопрос[/quote]
Не вижу проблем. Подготовить речь для клиента что все это плохо и это бомба замедленного действия. Запросить ХХХХХХ$ на переделку всего на lwc + apex. Если клиента это не устраивает то пожелать удачи в бизнесе и идти к другому клиенту. Клиентов/проектов много а ты один. Так нафига тратить свое время на поддержку/допилку говно-решений которые оставил твой предшественник???

Вот как вывод из этой темы давайте сформируем [b]список недостатков LCNC[/b], который можно будет использовать для аргументированного общения с клиентом. Почему LCNC плохо и к чему это может привести в долгой перспективе.

К примеру, вот это говно невозможно ни читать, ни дебажить. 

[img]https://d3nqfz2gm66yqg.cloudfront.net/images/20210614134532/Image_21.png[/img]

[quote="Dmitry Shnyrev"]можно будет использовать для аргументированного общения с клиентом. Почему LCNC плохо [/quote]

я не думаю, что в 2023 году у тебя еще есть такой вариант, если ты вообще хочешь работать с клиентом.
этот клиент начал этот проект, потому что повелся на LCNC. и уже видел своими глазами, что там много можно сделать интересного

есть только один вариант: как с этим жить, как митигировать импакт гавно-флоу на твой проект. а для этого нужно самому стать экспертов во всех этих LCNC тулах

как писал тот парень: "[i]Вам не отвертеться[/i]"

[quote="Den Brown"]я не думаю, что в 2023 году у тебя еще есть такой вариант, если ты вообще хочешь работать с клиентом.[/quote]

Тут я соглашусь, предложений стало куда меньше.
Самым правильным конечно будет сказать - флоу говно, вероятно столкнёмся с какими то косяками, но раз вам хочется, то можно. А потом когда что-то отвалится - переделывать на apex. По итогу будет опыт в флоу + денежка за работу, а потом денежка за переделку.

В целом большинству заказчиков не важно насколько инвалидски реализовано решение, ведь если работает, то работает.

гавно-код ничем не лучше чем гавно-флоу. но гавно-флоу все же лучше для клиента, там как ему его проще пофиксить или хотя бы понять.

сколько я помню Mulesoft, он всегда был LCNC тулом в основе которого было конфигурирование и декларативное программирование. при этом никто не говорит, что Mulesoft- это не серьезно, там "все иконки и картинки какие-то". так что Mulesoft был просто началом всех этих перемен

я думаю, что таким людям, как мы, нужно спокойнее относится к LCNC тулам, хорошо знать их и использовать везде, где это имеет смысл. и если в логике есть какой то момент, где только код поможет, вывести это в Action, но все равно в целом использовать Флоу. можно сказать - это новый уровень твоих программистских навыков - умелое жонглирование между кодом и Флоу

[quote="Den Brown"]я думаю, что таким людям, как мы, нужно спокойнее относится к LCNC тулам, хорошо знать их и использовать везде, где это имеет смысл. и если в логике есть какой то момент, где только код поможет, вывести это в Action, но все равно в целом использовать Флоу[/quote]
Хорошо, тогда скажите мне как работать двум разрабам над одним флоу? Вы забыли про git? Как мержить изменения. Как дебажить, скажем у меня не работает и мне надо вывести сериализованный в json List или Map. А как жить когда ты делаешь на сандбокс свой flow а клиент взял и на проде что-то поменял пока ты спишь, потому что
[quote="Den Brown"]все же лучше для клиента, там как ему его проще пофиксить или хотя бы понять.
[/quote]
В коде один Source of Truth и это git репозиторий. И что-то запороть в нем практически невозможно. А как вы представляете жизнь в более менее серьезном проекте где каждая собака идет и вносит изменения прямо на проде? Я помню на flow есть версии, но разве они помогают разрулить все вышеперечисленные проблемы?

лично я бы вообще сделал Production read-only и чтобы любые изменения можно было залить только через changeset или API. Никаких click решений и возможности повлиять на metadata даже админам разрабам. Вот тогда был бы порядок. Хочешь что-то поменять - делаешь сандбокс, меняешь и заливаешь changeset на Production. 

По ходу данной темы сильно заметно отсутствие опыта работы на реальных НЕ SF проектах (Java/.NET/Python). Наверное вам попадались исключительно проекты с мелкими клиентами где нужен максимум мелкий триггер/форквлов/флов максимум на посчитать какое-то поле или сделать небольшую валидацию.

А вы попробуйте запилить что-то типа уровня Jira на Salesforce. Посмотрю как вам LCNC помогут.

[quote="Dmitry Shnyrev"]А вы попробуйте запилить что-то типа уровня Jira на Salesforce. Посмотрю как вам LCNC помогут.[/quote]
А я скажу вам со сто процентной уверенностью что рано или поздно клиент вырастит из мелких флов и захочет что-то посерьезнее. 

Я считаю Salesforce просто уникальнейшим проектом аналогу которого нет из-за своего Apex/Visualforce/LWC. Покажите мне хоть одну другую CRM где возможно такое использовать (кроме 1С :smile:)? Такая гибкость кода в сочетании со стандартным UI это стоит многого. Так зачем отказываться от такого дара как код в пользу LCNC?????????????????????

Пока ни одного довода кроме "клиент туда может сам влезть и все сломать" в пользу LCNC я не услышал. 
Так что Apex Forever!!! :party:

[quote="Dmitry Shnyrev"]тогда скажите мне как работать двум разрабам над одним флоу? Вы забыли про git? Как мержить изменения. Как дебажить, скажем у меня не работает и мне надо вывести сериализованный в json List или Map. А как жить когда ты делаешь на сандбокс свой flow а клиент взял и на проде что-то поменял пока ты спишь[/quote]

вот именно именно именно поэтому я и начал эту тему. чтоб перечислит все засады и быть как-то к ним готовым.

[quote="Dmitry Shnyrev"]Пока ни одного довода... в пользу LCNC я не услышал.[/quote]

ты не осознал весь масштаб проблемы. во всех более менее крупных консалтинг конторах все менеджеры, директора, архитекты(кто сто лет не кодил и вообще уже едва соображает),все как загипнотизированные зомби повторяют "LCNC... LCNC...  LCNC.." и дирижирует этим сам... Salesforce

[quote="Den Brown"]ты не осознал весь масштаб проблемы. во всех более менее крупных консалтинг конторах все менеджеры, директора, архитекты(кто сто лет не кодил и вообще уже едва соображает),все как загипнотизированные зомби повторяют "LCNC... LCNC... LCNC.." и дирижирует этим сам... Salesforce[/quote]
Ну если с этой точки зрения и нет права выбора, то останется только подстраиваться под ситуацию и начинать изучать LCNC. Но а пока есть возможность пилить True Code решения, будем пилить эти самые решения.
А изучить те же самые Flow при необходимости не думаю что составит большого труда. За неделю я думаю можно освоить имея баграунд разработчика. 

ок, давай подведем какие-то итоги, друзья-флоуненавистники

(1) проблему с изменениями в проде решить невозможно (т.к. это не проблема, а фитча, спросите СФ), они это будут делать в любом случае. Но можно под страхом смерти требовать от них что-то писать в Description (здесь бы вообще внедрить какой-то change log) при изменениях, а также при работе с флоу в сендбоксе, каждый раз вначале делать push back флоу из прода. рефрешить сендбокс из-за каждого флоу апдейта не получится

(2) изучить вопрос с мерждем флоу метадаты. весь вопрос в том, насколько этот файл readable and understandable. здесь нужно просто пробовать

(3) знать все эти тулы ЛУЧШЕ чем те люди кто с ними работает. иначе ты будешь всегда зависим от их уровня профессионального развития, а это очень печальная судьба. если клиент LCNС - то уметь запилить флоу, ну такой в котором флоу - это логический каркас, и вся работа делает в апекс actions (к примеру)

(4) т.к. вся эта LCNC мания может быть началом каких-то сдвигов на маркете, то начать крутить головой в поисках "горячих" платформ. и хотя в СФ еще найдется работа на годы, он уже в стадии "дойной коровы", а это значит что новые клиенты могут вполне начать выбирать что-то дешевле и прикольнее. и конечно это будет LCNC платформа :smiley:

Может кому интересно будет 

IC2 последнее обновление

2.2.9.4
Issue 2468 - Graphical preview of Flow metadata
Inspired by [url=https://toddhalfpenny.com/2023/11/18/unleashing-power-salesforce-flows-introducing-flow-visualiser-extension-vs-code/?utm_source=product&utm_medium=link&utm_campaign=WS&utm_content=2023.3]Todd Halfpenny's wonderful work on a graphical viewer for Flow metadata for VS Code[/url], I've implemented similar for IC2. Now by default when you open a *.flow[-meta.xml] file in IC2, the default editor will feature a split view with the Flow XML on the left and a flowchart diagram on the right. This is the same IDE split editor component used for Markdown and SVG files and can be toggled to show only the source, only the preview, or both if desired. The preview is live and automatically updates as the Flow XML file contents change. The JetBrains Markdown (bundled) and Mermaid (freely-available via the plugin marketplace) plugins must be installed for this feature to be enabled. IC2 automatically assists with installation and enablement of these two plugins if necessary when Flow files are opened. The feature can also be disabled completely if desired by unchecking Illuminated Cloud | Configure Application | User Interface | Use preview editor for Flow Files.

спасибо за наводку. 
не знаю полезна ли сама идея graphical viewer for Flow metadata for VS Code, если это все есть в самом орге. 
А вот если бы можно было бы в графическом виде сравнить две флоу версии, вот это было бы здорово

[quote="Den Brown"]
А вот если бы можно было бы в графическом виде сравнить две флоу версии, вот это было бы здорово[/quote]
Предложи автору!!!

Вот вижу, что в выбор вариантов Флоу они добавили Флоу-аркистрейшен, фактически - это триггер-диспечер. Вижу с какой легкостью можно запилить кастомный ROll-Up функционал (для простых случаев) через Флоу. Они реально развивают тему LCNC. И это я еще не говорю про OmniStudio

такими темпами скоро программирование с помощью кода будет загнано в "гетто" хардкорной пакетной разработки

[quote="Den Brown"]они добавили Флоу-аркистрейшен, фактически - это триггер-диспечер.[/quote]

я бы сказал что Flow Orchestration больше Флоу-Диспечер - 
Действует как контейнер для других флоу, чтоб организовать всё как единый процесс, со статусами для каждого stage/step
+ новые виды флоу: 
Evaluation flow: условия для входа / выхода в оркестрацию или в stage.
Autolaunch используется кaк background step
Screen flow кaк Interaction step 
и ещё разные заморочки: reports, sharing, debug...

один из features - позволяет заморозить процесс, например послать клиенту майл и ожидать ответ, который может взять час, день или неделю.
когда ответ возвращается - ловиться как изменение поля, процесс просыпается и продолжает с того же места где остановился.

[quote="Eric"]

один из features - позволяет заморозить процесс, например послать клиенту майл и ожидать ответ, который может взять час, день или неделю.
когда ответ возвращается - ловиться как изменение поля, процесс просыпается и продолжает с того же места где остановился.[/quote]

вот то - то и оно. столько нового. не проспите все эти перемены :)

Eric, а ты откуда все это знаешь?

[quote="Den Brown"]Eric, а ты откуда все это знаешь?[/quote]
Наверное потому что Eric читает [b]Release Notes[/b] :smiley:
https://salesforce-developer.ru/salesforce-spring-24-release-1705424879176

[quote="Den Brown"]Eric, а ты откуда все это знаешь?[/quote]
:smile::smiley:
я использовал Flow Orchestration на проекте.

он вышел года два назад - GA
но с каждым релизом добавляют функционал

[quote="Dmitry Shnyrev"]Наверное потому что Eric читает Release Notes[/quote]
:rolling:
читать про все 800 новых features нет времени. 

есть достаточно того что Salesforce publish summaries основных features для admins and developers.
https://admin.salesforce.com/release-resources
+
Release in a Box - pdf file, несколько features для каждого product / cloud
Feature Release Matrix - excel в котором можно отфильтровать и легко найти какой нибудь feature

[quote="Dmitry Shnyrev"]читает Release Notes[/quote]

если ты не знаком с функционалом, не используешь его на практике, то читай - не читай Release Notes - ничего в голове не уложится и не запомнится

[quote="Eric"]я использовал Flow Orchestration на проекте[/quote]
ну давай, рассказывай. Flow Orchestration Flow - это просто такое модное название, или там есть свои фитчи?

Еще же есть [b]Flow Trigger Explorer[/b], довольно удобный, который фактически выполняет функцию "корневого" триггера-диспечера (как если бы это был апекс тригер)

и есть рабочий вопрос. Во Flow в ресурсах есть Text Templates, которые очень удобно использовать для Email Bodies.
И проблема в том что Email Bodies - это часто изменяемая вешь, и люди пытаются их менять прямо в Проде, и это можно понять. Есть большой Flow который использует Text Templates, и вот можно бы было как-то "отделить" эти все Text Templates в отдельный, но вовлекаемый в основной Flow, и тогда можно было бы сказать людям "Не трогайте в Проде основной Флоу, но можете вносить ваши изменения в служебный Флоу с Text Templates"

как бы это сделать?

И вот короткое видео про практическую OmniStudio:

https://www.youtube.com/watch?v=jVfIJLKQSUM

автор хорошо показывает, как OmniStudio (FlexCard and OmniScript)  можно использовать как для внешних, так и для внутренних пользователей. 

FlexCard and OmniScript фактически заменили стандартный лейаут для внутренних пользователей. LWC что-то уже нигде не видно.

Flow тоже показан, а апекс код если и есть, то он обретается где-то на задворках Flow Actions, для интеграции, к примеру

вот это - новая реальность. и она мне нравится

[quote="Den Brown"]И вот короткое видео про практическую OmniStudio:[/quote]
Автор кстати Salesforce Flow Product Manager.
на его есть сайте есть много полезного и готовых примеров по использованию flows
https://unofficialsf.com/

FlexCard and OmniScript можно изпользовать где подходит, едиственное что они доступны только если есть Industry licenses (Communication Cloud (Vlocity), Automotive Cloud, Financial Service (FSC)...) 

[quote="Den Brown"]ну давай, рассказывай. Flow Orchestration Flow - это просто такое модное название, или там есть свои фитчи?[/quote]

часть фитчей я уже написал:
возможность заморозить процесс и продолжить через какое то время.
+ 
возможность построить сложную логику (Evaluation Flow) чтоб решить начать оркестрацию или нет, то же самое для stage (группа steps).
в каждом stage может быть несколько степов, каждый из которых - отдельный flow с любой логикой что позволяет flow - get / update records, send email, invoke apex action, invoke callouts / external services...
Можно сделать условия когда запускать каждый степ, один за другим, параллельно. 

Flow Orchestration подходит если процесс multi-step/ multi-users  и надо относиться как одна "транзакция".

Несколько примеров использования:
[b]Employee Onboarding[/b] - разные пользователи с разных departmetns получают tasks (work items) - приготовить компютер, приготовить рабочее место... только когда все закончили, еmployee получает уведомление

[b]Order Fulfillment[/b] - update Salesforce records, update external Legacy systems (create order in ERP), send email to customer...  
[b]Knowledge Base / Any content document approval process[/b]

[quote="Den Brown"]и есть рабочий вопрос. Во Flow в ресурсах есть Text Templates, которые очень удобно использовать для Email Bodies.[/quote]
я не пользовался flow text template.

Может использовать email template вместо flow template
https://unofficialsf.com/send-better-email-flow-action/

Впечатляет. Полистал статьи с этого сайта, оказывается столько всего уже по теме Flow есть. Начинаю проникаться этой философией.

Чисто из любопытства. Недавно делал небольшую задачку на стандартной связке LWC+Apex. Интересно такое на Flow запилить можно? На Account кнопка (Screen Action LWC) - открывается модалка в которой есть пару полей (текст и дата) и таблица с контактами принадлежащими данному аккаунту, удовлетворяющими определенному критерию (пара полей на контакте проверяется). В таблице для каждого контакта показывается определенная информация собранная из связанных с контактом объектов. Есть чекбокс для выбора контакта. Внизу кнопка - которая берет заполненные поля в шапке и выбранных контактов, формирует json и посылает POST запросом на внешний API (через Apex естественно). Еще такой момент из обязательных требований к UI - контакты могут подходить по критериям для показа в таблице, но не иметь какой-то информации из связанных объектов, поэтому их нельзя выбрать (чекбокс задизейблин), плюс возможность выбрать/очистить все чекбоксы (select/deselect all). 

Не подумайте, не пытаюсь стебаться над Flow, просто реально интересно что-то подобное на Flow можно запилить и как. Если что-то такое возможно, то наверное пора и мне погрузиться в изучение этой темы. Тем более клиент постоянно на это намекает. Я просто пока даже не представляю даже на 1% текущие возможности Flow. Но Eric последнее время коснулся таких серьезных тем из Flow, что поражает.

С помощью Screen Flow такого не сделать, у него до сих скромные возможности, и возможно, что их преднамеренно не развивают, чтоб Screen Flow не начал конкурировать с OmniScript.

А вот с помощью OmniScript and FlexCard такое можно сделать, но для этого нужно знать OmniStudio и иметь ее в орге.

Для LWC, конечно, еще найдется работа для сложных кейсов

Посмотрел это видео чтоб лучше понять Flow Orchestration, но внезапно появились совсем другие вопросы:

https://www.youtube.com/watch?v=n39BPDOv1Wk

Eric, как они так лихо используют ScreenFlow в Work Guide компоненте? как он рендерит то один, то другой ScreenFlow?

 а возникшие вопросы по Mulesoft даже задать некому

[quote="Eric"]возможность заморозить процесс и продолжить через какое то время[/quote]

мы привыкли, что СФ - это record-centric system, т.е. система никаким образом не сохраняет state между событиями бизнес логики или пользовательского поведения, кроме как в записи.

а так получается, что создается instance этого флоу, который сохраняет state. Это большая перемена, требующая полного переосмысления используемых подходов.

и появляются новые вопросы: как много flow instances системы может хранить? как организовать удаление "мертвых" флоу, сколько их "ждать", на какой стадии удалять?

PS: смотрю время от времени видео с CTA mock-up и там во время презентации решений говорят: "флоу здесь, флоу там, флоу сям". "Апекс тригер" уже даже не звучит, и вспомнить его - это серьезный риск прослыть отсталым и ретроградным :)

[quote="Den Brown"]и появляются новые вопросы: как много flow instances системы может хранить? как организовать удаление "мертвых" флоу, сколько их "ждать", на какой стадии удалять?[/quote]

есть существующий лимит 50000 paused interviews

в setup menu есть "Paused And Failed Flow Interviews" - видно все flows которые в ожидании.

в Flow Orchestration есть главный объект "Orchestration Run" + таб с listview
каждую оркестрацию можно отменить ("Cancel Orchestration"): вручную или automation, естественно если она только ещё не закончилась.


по поводу CTA mocks - по теории практически всегда лучше предложить customization solution вместо development,  иначе начинаются вопросы про оптимальный и менее оптимальный solution...:rolling::so-sad:

[quote="Dmitry Shnyrev"]просто реально интересно что-то подобное на Flow можно запилить и как.[/quote]

для сложной UI логики, без LWC пока что не обойтись. :party:

в Flow добавили DataTable component и расширяют по немногу.
https://www.linkedin.com/pulse/datatable-component-salesforce-screen-flow-a-engin-utkan/
https://salesforcetime.com/2023/06/16/data-table-component-in-screen-flow/


в том же сайте - связка Flow-LWC-Apex
https://unofficialsf.com/datatable-lightning-web-component-for-flow-screens-2/

[quote="Eric"]в Flow добавили DataTable component и расширяют по немногу.
https://www.linkedin.com/pulse/datatable ... n-utkan/[/quote]

Мы это сделали через свой компонент. Он более мощный. Так же  позволяет получать Input и отправлять Output

[quote="Den Brown"]а так получается, что создается instance этого флоу, который сохраняет state.[/quote]

пока для простоты восприятия, про  Flow Orchestration я думаю как про super advanced Approval Process. Approval Process - он тоже как то мог хранить свой state, реагировать на события, мог быть направленным к определенным людям

[quote="Den Brown"]пока для простоты восприятия, про Flow Orchestration я думаю как про super advanced Approval Process. Approval Process - он тоже как то мог хранить свой state, реагировать на события, мог быть направленным к определенным людям[/quote]

можно сказать и так.
+ есть доступ к объект который хранит state - Orchestration Run

Продолжаю работать с Flow и замечаю все новые и новые "плюшки":

(1) Совершенно удобный Flow Trigger Explorer на объекте, который выполняет функцию Апекс-Триггера-Диспетчера. В нем можно открыть окно с версиями какого-то Flow, активировать, деактивировать их. Все в одном месте.

(2) Удобный дебагинг Flow: в большом Flow выполненный "путь" просто подсвечивается, что прям красота. Видно как "шел" процесс, где и почему остановился. При этом сама запись не изменятся, емейлы не отправляются и, вероятно, другие записи не создаются и не изменяются в реальности по ходу выполнения дебаг-прогона флоу.

(3) В дебаг редакторе есть кнопка "Convert to Test", что просто круто. 

Так что у меня язык не поворачивается назвать весь этот Flow функционал "отсталым и недоразвитым"

[quote="Den Brown"](3) В дебаг редакторе есть кнопка "Convert to Test", что просто круто.[/quote]

А вот это уже  интересно

еще сделал неожиданное открытие о Флоу

вот в этом совершенно нехитром видео автор рассказывает как использовать table component in Screen Flow:
https://www.youtube.com/watch?v=MZpKcHolw7M

в целом простота работы и результат создают хорошее впечатление и если этот table component может редактировать записи и ЕСЛИ его можно подключить к кастомным данным из апекс action, то вполне возможно получится сделать, что хотел Дмитрий.

но главное не в этом.

что такое Screen Flow в моем представлении? это [b]процесс[/b], состоящий из несколько шагов (скринов), который имеет ясные начало и конец, и часто инициируется нажатием кнопки. Да, я знал, что Screen Flow можно выложить в виде компонента на Lightning page, но предполагалось, что это будет все тот же [b]процесс[/b], и то, что изначально видно в Lightning page компоненте, это просто его первый шаг.

но автор ролика с помощью Screen Flow запилил просто UI component. Просто read-only UI component (а мог бы и не только read-only), т.е. Screen Flow используется как UI component builder!

И знаете, если так вот просто можно запилить кастомный табличный компонент - то это большое дело

[quote="Den Brown"]вот в этом совершенно нехитром видео автор рассказывает как использовать table component in Screen Flow:
https://www.youtube.com/watch?v=MZpKcHolw7M[/quote]

Просматриваю видосы и заметил пару общих недостатков для меня во flow которые пока отталкивают.

Когда ты разрабатываешь flow ты должен иметь в голове и делать уже полностью рабочий flow. В коде я к при меру привык делать сначала статический шаблон, потом накидывать dummy data, потом брать реальные данные. То есть мой код растет не сверху вниз, а как снежный ком увеличивается. От простого к сложному. Пока то что я вижу в видосах flow - каждый шаг зависит от предыдущих. 

Не понял (пока не увидел) также как можно закоментировать (обойти) какую-то часть flow когда нужно отключить кусок функционала на время. 

Еще один момент пока непонятен. А как же копипаст? Вот есть у меня flow похожий, но я не хочу выносить и делать общую часть, а просто хочу скопировать большой кусок flow, внести пару изменений мелких и сохранить как новый - мне опять все с нуля накликивать?.

[quote="Dmitry Shnyrev"]Когда ты разрабатываешь flow ты должен иметь в голове и делать уже полностью рабочий flow. В коде я к при меру привык делать сначала статический шаблон, потом накидывать dummy data, потом брать реальные данные. То есть мой код растет не сверху вниз, а как снежный ком увеличивается. От простого к сложному. Пока то что я вижу в видосах flow - каждый шаг зависит от предыдущих.

Не понял (пока не увидел) также как можно закоментировать (обойти) какую-то часть flow когда нужно отключить кусок функционала на время.

Еще один момент пока непонятен. А как же копипаст? Вот есть у меня flow похожий, но я не хочу выносить и делать общую часть, а просто хочу скопировать большой кусок flow, внести пару изменений мелких и сохранить как новый - мне опять все с нуля накликивать?.[/quote]

а вот тут-то и может проявиться твой опыт реального программирования, а не просто "мышко-кликания". но надо знать весь функционал Флоу. 

может вывести весь функционал в субфлоу? 
а может ли субфлоу возвращать результат в основной флоу? 
а может скачнуть метадату того Флоу и что-то скопипастить оттуда?

[quote="Den Brown"]а может скачнуть метадату того Флоу и что-то скопипастить оттуда?
Цитировать
[/quote]

Млжно,  но черевато проблемами, ввиду зависимостей

Не много прошло времени, а темы всплыла. На днях у клиента появился человек который "знает" flow. У нас в проекте хотелки часто реализуются с LWC Quick Action. На очередную хотелку новый товарищ заявил что сделает ее с помощью Flow (Screen Flow я так пониамаью). Эх, посмотрим куда заведет нас эта кривая дорожка. И когда меня попросят "посмотреть что там не работает" или вернут таску на переделку под LWC :smiley:. А возможно все будет хорошо :smiley:

[quote="Dmitry Shnyrev"]Не много прошло времени, а темы всплыла. На днях у клиента появился человек который "знает" flow. У нас в проекте хотелки часто реализуются с LWC Quick Action. На очередную хотелку новый товарищ заявил что сделает ее с помощью Flow (Screen Flow я так пониамаью). Эх, посмотрим куда заведет нас эта кривая дорожка. И когда меня попросят "посмотреть что там не работает" или вернут таску на переделку под LWC :smiley:. А возможно все будет хорошо :smiley:[/quote]

Интересно что получилось в результате

[quote="EvAzi"]Интересно что получилось в результате[/quote]
Ничего не получилось. Переиначили все буквально на следующий день. Сказали делать на Quick Action как раньше. Хз что там произошло, может не потянули или эстимейт не устроил. 

вот недавно делали деплоймент новых фитчей для существующего проекта. тот проект изначально делался по максимума на LCNC и в change set-е были в основном апдатированные старые флоу, часто здоровучие такие.

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

и если джуны, кто апдатировал эти флоу, как-то накосячили (а они обязательно накосячили) - я легким движением руки могу активировать предыдущую версию флоу прям в Проде, делов то

[quote="Den Brown"]и мне было так легко и приятно на душе, что для всех этих флоу мне не надо искать и фиксить их старые тест классы, которые обычно уже фейляться, т.к. изначально были сделаны не правильно.[/quote]
Не совсем понял, то есть ты радуешься что тесты падают но для флоу это не важно и ты можешь флоу задеплоить даже несмотря на то что сломаешь всю бизнел логику на проде?
Как то не очень звучит.

Я вот тестам просто готов пямятник ставить. За последние пару лет написал столько кода что уже сам не вспомню что написал. Но каждый раз благодаря тестам которые писал под ту старую логику, могу отловить косяки на этапе деплоя и это только радует. По мне тесты важнее самого кода! Да порой лень писать, но если написал и покрыл тестами основные варианты использования кода то 99% что эту ночь будешь спать спокойно. 

Поэтому твой аргумент скорее анти-аргумент

[quote="Den Brown"]и если джуны, кто апдатировал эти флоу, как-то накосячили (а они обязательно накосячили) - я легким движением руки могу активировать предыдущую версию флоу прям в Проде, делов то[/quote]
А с правильными тестами и кодом всякий говнокод даже не дойдет до прода :smiley:

[quote="Den Brown"]и если джуны, кто апдатировал эти флоу, как-то накосячили (а они обязательно накосячили) - я легким движением руки могу активировать предыдущую версию флоу прям в Проде, делов то[/quote]
Хорошо, такой вариант развития событий - я задеплоил флой он работает не так как нужно - ты другой разраб взял и откатил на проде на предыдущую версию. Я что должен делать? Я откуда узнаю об этом? 

[quote="Dmitry Shnyrev"]Я что должен делать? Я откуда узнаю об этом?[/quote]
Для меня это вообще больная тема. Мне еще не так страшно - клиент/босс научился работать с дата моделью, лайаутами и репортами. Он может насоздавать своих полей, начать их использовать (пока для Флоу еще не добрался). Мне каждый день приходится выяснять что за поля он насоздавал, приходится переносить их на дев орг и добавлять в репозиторий чтобы другие разрабы могли себе задеплоить. Это отнимает кучу времени и нервов. Даже представить не могу чтобы было с флоу. По мне прод надо делать read-only для метадаты и позволять изменять что либо исключительно ченжсетами с сандбоксов.

я вижу на ЛинкедИне, что есть конторы, которые продают на АпексЭксчендж кастомные компоненты для Screen Flow, или дают советы как улучшать их с помощью CSS.

И при этом начинающие разрабы активно лайкают такие посты, то есть они явно интересуются и заинтересованы темой.

Все это дают мне ощущение, что новое поколение разрабов будет рассматривать LCNC как деволтный способ работы, вся движуха будет вокруг LCNC - а заинтересованные люди - это самое главное. Значит тему будет продвигать как СФ, так и коммунити, улучшая и улучшая возможности LCNC инструментов.

А то, что пара старых бородатых разрабов будет обиженно "пыхтеть" про LWC и важность апекс-тестов, да кого это интересует

[quote="Den Brown"] при этом начинающие разрабы активно лайкают такие посты, то есть они явно интересуются и заинтересованы темой.[/quote]
Лннкедин показатель? Там седят одни эйчары и джуны после курсов в попытке найти работу. Естественно они лайкают все подряд чтобы из заметили и пригласили. Трушные старые разрабы просто занимаются работой, им некогда сидеть на этой помойке.

[quote="Den Brown"]А то, что пара старых бородатых разрабов будет обиженно "пыхтеть" про LWC и важность апекс-тестов, да кого это интересует
Цитировать
[/quote]
Пыхтел и буду пыхтеть. Моя бы воля сделал бы весь прод read-only. Как напрягает каждый день удивляться что за ночь успела накликать команда клиента.

[quote="Dmitry Shnyrev"]
Пыхтел и буду пыхтеть. Моя бы воля сделал бы весь прод read-only. Как напрягает каждый день удивляться что за ночь успела накликать команда клиента.[/quote]

Для этого должен быть документ Way of Work и все должны его придерживаться