Introduction to Salesforce flows. Part 2

Всім привіт, сьогодні ми продовжуємо нашу серію статей про Salesforce Flow і пропонуємо вашій увазі статтю “Introduction to Salesforce flows. Part 2” (із першою частиною ви можете ознайомитись тут).

Як вам вже відомо, Salesforce пропонує ряд гнучких та потужних інструментів для автоматизації процесів, і одним з таких інструментів є Auto-Launched Flow, який у свою чергу поділяється на Schedule-Triggered Flow, Record-Triggered Flow, Platform Event-Triggered Flow і Auto-Launched Flow (No Trigger). У цій статті ми зосередимось на Record-Triggered Flow.

Для початку давайте зрозуміємо, що взагалі таке Auto-Launched Flow і для чого він потрібен? Auto-Launched Flow - це процес, який спрацьовує без активної участі користувача і означає, що він може виконувати завдання без будь-якого зовнішнього втручання. Це особливо корисно в сферах, де потрібно автоматизувати рутинні завдання, звільняючи людей від набридливої, монотонної роботи.

Одним із основних підтипів Auto-Launched Flow є Record Triggered Flow, який використовується для автоматизації подій, пов’язаних зі змінами записів у Salesforce. Він може спрацьовувати при створенні, редагуванні та видаленні запису, і також ми маємо можливість вказувати свої додаткові умови. Але крім цього треба розуміти, що такі Flow поділяють ще на два типи: before та after.

Before-тригери спрацьовують до того, як запис буде збережено в базі даних. Ці тригери використовуються, переважно, для валідації і модифікації даних запису до їхнього фактичного збереження в базі.

After-тригери спрацьовують після того, як запис вже збережено в базі даних. Ці тригери зазвичай використовуються для завдань, які не впливають на сам процес збереження, але вимагають дані із запису для власної роботи.

Розглянемо приклад:

Коли новий контакт (Contact) зберігається в системі, Record Triggered Flow може перевірити його тип та відправити листа.

Для цього створюємо новий Flow та обираємо його тип - Record Triggered Flow

Далі налаштовуємо умови запуску наступним чином: обираємо бажаний об’єкт, налаштовуємо його спрацювання на створення запису (A record is created) та за бажанням вказуємо якісь додаткові умови.

У нашому випадку доцільним буде використання типу After, оскільки ми збираємось надсилати лист після збереження контакту у системі.

Наступним кроком ми створюємо та налаштовуємо елемент Flow, який відповідає за відправку листа на email адресу з контакта. Для цього створюємо новий елемент та обираємо його тип - Send Email Alert, після чого переходимо у розділ Core Action, де за допомогою пошуку знаходимо Send Email Action.

Настав час додати контент до нашого листа та визначити адресу, на яку ми маємо його надіслати. Для цього ми переходимо до розділу Set Input Values for the Selected Action та чекбоксом вмикаємо дві змінні: Body та Recipient Address List. Для Body ми створюємо або обираємо існуючу змінну, яка містить текст нашого листа, а у Recipient Address List ми маємо покласти дані з поля Email поточного рекорду, який запустив наш Flow. Додатково обираємо тему листа, оскільки це є обов’язковим полем даного елемента.

Зберігаємо всі налаштування елементу, також зберігаємо наш Flow, після чого активуємо його. Створюємо новий запис контакту та для перевірки вказуємо нашу електронну адресу. Переходимо на пошту та бачимо лист приблизно такого вигляду, а це означає що наша автоматизація відпрацювала як і очікувалось.

Тож у цій статті ми розглянули основи Auto-Launched Flow і більш глибоко занурились у Record-Triggered Flow. Auto-Launched Flow є потужним інструментом для автоматизації бізнес-процесів, які дозволяють ефективно керувати даними та взаємодіяти з користувачами, а Record-Triggered Flow у свою чергу не тільки полегшує рутинні завдання, але й робить бізнес-процеси більш ефективними та надійними зменшуючи людський фактор. Знання та розуміння цих концепцій допоможе вам ефективно впроваджувати автоматизацію у вашому Salesforce середовищі.

А вже у наступній статті ми запропонуємо вам розглянути такий цікавий тип Auto-Launched Flow як Auto-Launched Flow (No Trigger) і дізнатись, для чого потрібен він і як ним користуватись.

6 Вподобань

Flow - это один из Low Code / No Code тулов, доступных для СФ разработки. И реальность в том, что компании (как СФ) прикладывают сегодня максимум усилий, чтобы перенести разработку и кастомизацию на Low Code / No Code рельсы. И такой подход имеет много плюсов, но есть и минусы. Если есть заинтересованные в теме, давайте это обсудим, каковы плюсы и минусы разработки с помощью Low Code / No Code тулов. Как никак, но это новая реальность которая уже никуда не денется

Для себя я вывел формулу работы с Flow в СФ. Если в моём Flow содержится больше 20 квадратиков, я переношу логику в apex после чего убиваю этот Flow. В моей практике я очень много раз, думаю как и все Вы, сталкивался с ситуацией когда первоначальная задача поставленная клиентом была простой и укладывалась в концепцию небольшого “легковесного” Flow (за 20 минут набросал квадратиков накликал условий и не заморачивался необходимостью написания тестов для деплоя :slight_smile: ) и всё красиво, однако у клиента возникают по ходу эксплуатации дополнительные требования и как всегда не тривиальные (хочу чтобы в понедельник когда идет дождь и луна находится в козероге скидка на носки расчитывалась относительно привязки к стоимости бареля нефти в Зимббаве) что приводит к разбуханию нашего изначально простенького Flow до размеров монстра который поддерживать уже нет ни сил ни желания.

3 Вподобання

а чем монстр-код лучше монстр- Flow? во Flow хотя бы все “визуально” и не надо каждому админу объяснять какую логику Flow выполняет

1 Вподобання

Я делаю свои выводы с точки зрения программиста, а не администратора. Читать код мне проще, поиск по коду используемой переменной или анализ функций вызываемых из других классов и т.п. Современные IDE стали гораздо умнее и дружелюбнее. Два вложенных цикла в коде не проблема с точки зрения анализа понимания чего там происходит, а вот во Flow это уже может вызвать некое замешательство когда смотришь на кучу квадратиков и стрелочек которые туда сюда направлены и не всегда можно красиво расставить все квадратики чтобы стрелочки не пересекались или не накладывались друг на друга (это у меня осталось еще из Visio когда я блок схемы рисовал).
Мне нравиться расставлять квадратики красиво во Flow чтобы было понятно что за чем идет. На это у меня уходит некоторе время после того как логика уже реализована.
Я не говорю что разобраться нельзя, но сложность кода мне анализировать легче чем Flow.
Для админов безусловно Flow - это очень хорошее подспорье в автоматизации.
В любом случае у клиента точно в штате будет админ, который применив “мышко-ориентированное” программирование удовлетворить запросы своей команды, не привлекая программистов и не тратя попусту деньги компании.

1 Вподобання

И еще из недавнего, посчастливилось мне плотно разбираться и реализовывать портал для обслуживания клиентов с помощью платформы Titan ( Powerful no-code digital experiences for Salesforce). Клиент решил перейти от стандартного портала реализованного на платформе Community Cloud и создать портал в Titan-e, насмотревшись их обучающих роликов где они на примерах одностраничных форм с несколькими полями и кнопками рекламируют no-code подход.
После глубокого погружения в данную платформу я сделал вывод для себя что уж лучше вместо no-code там таки присутствовал code! То что в коде можно было бы реализовать с помощью 20-ти строк, no-code подход превращает в чудо природы на которое страшно даже смотреть :slight_smile:

Когда человек не знает программирования и не осознает что написав несколько строк можно сделать то что требуется, тогда no-code подход с квадратиками и стрелочками для него является логичным и единственным вариантом решения поставленной задачи. И это верно и правильно. Но когда ты программист и понимаешь что эту задачу можно было решить в 10-ть строк кода, а ты сидишь и рисуешь кучу квадратиков только потому что платформа по другому не позволяет это сделать, это немного выводит из себя :slight_smile:

1 Вподобання

оказывается, что вот такие вещи существуют, и это при том что сам Experience builder is LC/NC tool и SF активно раскручивает свой аналог - OmniStudio. Так что вся эта эпидемия low code/ no code тулов - это вряд ли временная мода, скорее это будущее, которое придется принять и обнять как родного

1 Вподобання

No Code позволяет снизить затраты компаниям на типовые задачи, снижая требования к сотруднику выполняющую автоматизацию. А если стоимость сотрудника на No Code ниже чем полноценного программиста, а результаты сопоставимы (критерий - решение бизнес задачи и получение прибыли ) то и спрос на No Code будет рости до определенного момента и стабилизируется потом. Программисты же будут привлекаться для решения более сложных и комплексных задач. Упрощая - для замены колеса на авто не нужно ехать в сервизный центр, а можно воспользоваться ближайшим шиномонтажом.

1 Вподобання

по факту “революция” NCLC уже свершилась в СФ. И программирование с помощью кода уже “отжато” в “гетто” пакетной разработки, или на периферию Flow Actions для интеграционных задач и прочей жести. Тут важно не упустить момент и правильно сориентироваться

Это верно только для свежих оргов с хорошим архитектором и относительно четкой постановкой задачи бизнесом.
На оргах, отягченных легаси (необязательно реализованным на коде) No Code подход в основном используется для простой автоматизации, которая к тому же не особо пересекается с существующими решениями.
Плюс при всей кажущейся легкости No Code подход порой требует тех еще танцев с бубном (о чем верно заметил @Vladislav_Styopin), да и ограничения все еще существенны.
Так что “гетто” пока что занимает как минимум 80% территории и на оргах отличных от примитивных для него еще долго будет работа

1 Вподобання