Хотите создать формы на Salesforce Platform? У вас есть несколько вариантов, охватывающих всю непрерывность от низкого кода до прокода. Низкокодовые представляют динамические формы в конструкторе приложений Lightning и потоки окон в Flow Builder. Посреди континуума висит возможность расширения потоков окон посредством LWC и создания форм, ориентированных на клиента, посредством OmniStudio. А прокод представляет собой инфраструктуру LWC и постоянно растущую библиотеку базовых компонентов.

Варианты отличные, но как определить, какой из них (или какая комбинация) является правильным вариантом? Здесь появляется это руководство.

• Takeaway #1: При создании/ редактировании/ просмотре макетов для страниц Lightning используйте динамические формы. Макеты страниц отсутствуют в сравнительных таблицах в данном руководстве. В дальнейшем рекомендуемый способ настройки страниц сведений о записях - использование динамических форм в конструкторе приложений Lightning. См. раздел «Макеты страниц» для получения дополнительных сведений о том, почему они не расширяются.
• Takeaway #2: Если вам нужно создать форму создания или редактирования для одного объекта, начните со страниц Lightning и динамических форм. Это самый простой способ создания форм на Salesforce Platform. Он также предоставляет некоторые дополнительные функции, например, возможность управления доступностью поля. Если ваши требования расширены, продолжайте читать. Поток окон, OmniStudio или веб-компоненты Lightning (LWC) могут подойти лучше.
• Takeaway #3: Если вы создаете многостраничную форму или мастер и не предъявляете строгих требований к UX или фирменному стилю, начните с потока окон. Потоки окон предоставляют линейную инфраструктуру навигации для оркестрации нескольких форм вместе. Вы можете использовать LWC для создания собственной инфраструктуры для навигации между формами, но мы рекомендуем разрешить потоку выполнять сложную работу, чтобы вы могли сосредоточиться на самих формах, а не беспокоиться о состоянии формы.
• Takeaway #4: Если вам нужна дополнительная логика или действия за формой, используйте поток окон, OmniStudio или LWC. Все три инструмента предлагают способы выполнения решения, выходящие за рамки создания или редактирования одной записи. Это может быть более расширенная логика, например, ответвление или итерация, или это могут быть более активные действия, например, интеграция с внешними системами, отправка электронной почты или всплывающие уведомления в мобильное приложение пользователя.
• Takeaway #5: Есть сложные требования к UX? Требуется динамическая обработка не только доступности? Используйте LWC или Omniscript. Если ваши требования могут быть выполнены с помощью простых тем и макетов на основе столбцов, вы можете создать формы напрямую в низкокодовом конструкторе. Для более точного контроля над стилем формы вам нужна максимальная гибкость LWC. Если вы являетесь клиентом отраслей и вам нужен пиксельный фирменный стиль или у вас есть сложные иерархические данные, используйте OmniStudio, что позволит вам создать формы уровня потребителя, которые могут обрабатывать сложную бизнес-логику и трансформации данных.
• Takeaway #6: Если вам нужна автоматизация тестирования, начните с Lightning Web Components. Вы можете написать единичные тесты для любого LWC, вне зависимости от того, куда вы планируете его встроить. Это дает возможность создать более надежную стратегию тестирования, которая может содержать пакетное тестирование с несколькими записями и отрицательное тестирование. См. Salesforce Хорошо архитектура - Стратегия тестирования для получения дополнительных сведений о создании тестов, которые помогут вам увидеть, насколько формы будут соответствовать вашим функциональным и нефункциональным требованиям.

Помните, что ваш выбор не обязательно должен быть «или» - вы можете объединить силу нескольких вариантов. Например, если вам нужна встроенная система навигации Flow и полная гибкость оформления, предлагаемая LWC, используйте их вместе.

Таблица ниже содержит инструменты, доступные для создания форм в Salesforce, а также их обязательные навыки и рекомендации по лицензиям. Позже мы подробно рассмотрим конкретные функции, поддерживаемые для каждого инструмента, а также способ выбора между инструментами на основе клика и инструментами на основе кода (и время их сочетания):

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

Ниже указаны термины, используемые в сравнительных таблицах вместе с их определениями:

• Доступно: Работает нормально с основными рекомендациями.
• Не идеально: Может работать, но не является оптимальным инструментом.
• Дорожная карта: Примерная поддержка в течение следующих 12 месяцев (июнь 2025 года).
• Будущее: Предполагается, что поддержка будет оказана после следующих 12 месяцев.
• Недоступно: Нет планов поддержки этой возможности в течение следующих 12 месяцев.

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

Если форма работает против одного объекта Salesforce, сработает любой из сравниваемых инструментов. С кросс-объектными или объектно-агностическими формами все немного усложняется. Под объектно-агностическими мы понимаем вводные данные, которые не соотносятся с объектом Salesforce. Возможно, форма представляет структуру данных, отправляемую во внешнюю службу (например, Stripe или DocuSign). Или, возможно, вы используете несколько вводных данных в форме для вычисления значения, а потом подтверждаете это значение в базе данных.

• Против каких объектов будет действовать форма?
• Это только один объект или есть несколько объектов?
• Работаете ли вы с определенными объектами (например, организация, контакт, возможность, интерес и обращение) или форма должна также работать с другими объектами?

В кросс-объектных и объектно-агностических формах поток и OmniStudio являются надежными вариантами. Компоненты, доступные в окнах потока, агностичны по природе, поэтому можно выбрать фоновое использование этих данных. Например, используйте данные, введенные в одной форме, чтобы создать несколько записей в фоновом режиме или используйте данные для выполнения других действий, например, создания сообщений Chatter, отправки сообщений Slack, отправки электронной почты или подключения к внешним службам.

В простых случаях использование существующих компонентов LWC, например, Lightning- record-form, может быть простым способом снизить код, необходимый для предоставления надежного решения. Однако, для сценариев, где задействовано несколько объектов, поток предоставляет комплексный контроль для всех объектов и снимает необходимость для разработчиков преодолевать сложные взаимосвязи и зависимости.

OmniStudio делает шаг вперед и полностью агностичен объекту — он отделяет форму, отображаемую пользователю, от основной модели данных. Вместо этого, OmniStudio манипулирует базовым JSON, который потом соотносится с объектами Salesforce (или внешними данными) посредством таких инструментов, как Data Mapper и Процедуры интеграции. Процедуры соотнесения данных и интеграции являются двумя ключевыми компонентами подключения форм OmniStudio к внутренним и внешним данным Salesforce. Используя элементы перетаскивания, можно работать со сложными иерархическими данными во внешней системе, а потом трансформировать данные в соответствии с вашими потребностями, в зависимости от того, куда данные нужно направить. Они также позволяют использовать формулы для выполнения математических и логических действий над массивами, или списками данных, примерно как Apex.

Интеграции OmniStudio

Если вы можете получить все вводные данные пользователя из формы с одним экраном, начните с динамических форм. Однако, хотя динамические формы на страницах записей могут использовать функцию «Путь» для свободного представления разных этапов бизнес-процесса, она может не соответствовать большинству ваших способов использования.

• Нужен ли один экран или пользователю нужно переходить между несколькими экранами для выполнения задачи?
• Хотите ли вы, чтобы пользователи видели визуальное изображение того, как далеко они продвинулись в процессе заполнения формы?
• Будут ли пользователи обязаны заполнять сведения на каждом экране в определенном порядке или они должны иметь возможность перемещаться между экранами?

Если вам нужно больше функций, чем предлагают динамические формы, выбор между Flow, OmniStudio и LWC будет зависеть от нескольких других вопросов:

• Какие навыки есть у вашей команды? Для организации с большим количеством администраторов рекомендуем начать с потока. Если у вас есть решения Industries, ваша команда уже знакома с OmniStudio, и у вашего проекта строгие требования к UX, начиная с OmniStudio.
• Можно ли отобразить панель навигации внизу формы? Если поток окон и взаимодействие навигации Omniscript нежелательно UX, склонитесь к LWC.
• Что должно произойти за формой? Если вам нужно, чтобы поведение настраивалось администратором, создайте поток или — для базовых изменений, например, изменения меток полей — Omniscript. В противном случае, для сложных многообъектных взаимосвязей создайте Omniscript или LWC.
• Если вы выберете Flow или OmniStudio, возможно, вам потребуется создать LWC для достижения правильного UX. Если вы уже создаете LWC для корректного оформления формы, подумайте, является ли встраивание этого компонента в поток перебором.

Если, с другой стороны, ваше решение выглядит как мастер, где пользователь переходит между несколькими экранами, обратите внимание на Flow или OmniStudio. Потоки и OmniStudio поставляются со встроенной моделью навигации, поэтому вам не нужно создавать и обслуживать LWC, сцепленные вместе. Навигация линейная, с действиями перемещения вперед, действиями перемещения назад и механизмом сохранения формы на потом. Можно также создать форму с нелинейной навигацией, если она соответствует вашим целям. Прекрасный пример использования потоков окон см. в пакете «Цифровой аудит магазина» Salesforce Labs.

OmniStudio предлагает ключевое навигационное преимущество, предоставляя индикаторы прогресса из стандартной навигации, которая отображает «этапы» в форме. Это представление этапа автоматически отображает расположение пользователя в заданной многоэтапной форме. В отличие от потока, он позволяет пользователям прыгать между экранами, нажимая на разных этапах формы.

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

При встраивании формы на стандартную страницу записи Lightning подойдет любой из сравниваемых инструментов с той оговоркой, что динамические формы в данный момент доступны только на ПК. Однако, если вы хотите предоставить взаимодействие, позволяющее пользователям получать доступ к формам из других расположений, возможно, вам потребуется рассмотреть альтернативные варианты.

• Потребуется ли пользователям доступ к форме посредством ПК, мобильного устройства или двух устройств?
• Должны ли пользователи иметь доступ к форме из любой области приложения посредством служебной панели?
• Хотите ли вы использовать быстрые действия, чтобы пользователи могли заполнить форму, не покидая страницу, на которой они сейчас находятся?
• Требуется ли доступ к форме на внешнем веб-сайте?

Поскольку они требуют контекста записи, динамические формы поддерживаются только на страницах записей Lightning. Однако, динамические формы не поддерживаются на страницах Experience Cloud. Это ограничение существует, поскольку Experience Cloud не использует базовую инфраструктуру, от которой зависят динамические формы: Страницы Lightning. Мы оцениваем это на основе запросов динамических форм в Experience Cloud.

Вы можете создать потоки, требующие контекста записи или потоков, работающих глобально. Таким образом, потоки можно встроить в разные расположения. Для потоков контекста записи это может быть страница записи Lightning, страница записи Experience Cloud, объектное действие или развертывание действий и рекомендаций. Для глобального потока это может быть панель служебных программ, другие страницы Lightning или конструктора взаимодействий, Snap или внешнее приложение. Потоки в настоящее время не поддерживаются как глобальные действия, но в качестве временного решения можно добавить поток в компонент Aura.

OmniStudio позволяет создавать составные FlexCards и Omniscripts, которые можно разместить практически в любом месте, где можно разместить поток. Однако, хотя они составимы, они не пакетируются.

LWC поддерживает высокую степень многоразового использования, поскольку вы создаете компоненты, которые можно связать с целями посредством метаданных в Salesforce, сообществах и даже в открытых проектах. Компоненты LWC также можно встроить в собственный веб- сайт посредством Lightning Out.

Out на внешних сайтах

Веб-компоненты Lightning в данный момент не поддерживаются как быстрые действия (объектные или глобальные), но в качестве временного решения можно завернуть LWC в компонент Aura (подобно тому, как это можно сделать с потоками). Компоненты LWC также могут запускать потоки посредством компонента Lightning-flow.

OmniStudio преуспевает в предоставлении содержимого внешним сайтам посредством функции OmniOut. С помощью OmniStudio и OmniOut можно компилировать формы Omniscript и компоненты FlexCard в стандартные компоненты и запускать их вне платформы на сторонних сайтах или в приложениях.

Ни одна из технологий форм, описанных в этом руководстве, сегодня официально не поддерживается в шаблонах Mobile SDK. Если Mobile SDK важен для вашего сценария использования, вам лучше создать форму нативно в мобильном приложении или создать страницу Visualforce, учитывая рекомендации по форм- фактору Salesforce Well-Architected.

Примечание к дорожной карте: Группа Mobile SDK активно работает над поддержкой LWC на страницах Visualforce.

Динамические формы идеально подходят, если вам нужно использовать значения в форме для создания или обновления записи. Для любых возможностей за пределами нужно использовать Flow, OmniStudio или LWC. Эти возможности могут включать уровень принятия решения или итерацию, либо создание сообщений Slack или сообщений эл. почты посредством вводных данных из формы.

• Какие действия или логику вы хотите выполнять в фоновом режиме?
• Содержит ли ваша модель данных иерархические данные?
• Нужно ли будет завершить операции формы в одной транзакции или в нескольких транзакциях?
• Требуется ли интеграция с внешними системами?
• Каковы ваши требования к многоразовости и модульности?

Flow предлагает стандартные действия для публикации в Slack, отправки электронной почты и взаимодействия с документами Quip, поэтому не нужно писать код для этих операций. LWC предлагает широкое взаимодействие с отдельными записями и связанными объектами посредством использования проводных адаптеров, взаимодействующих с пользовательским интерфейсом API. LWC также может взаимодействовать с несколькими записями при использовании провода для getListInfoByName.

Взаимодействие веб-компонентов Lightning посредством проводных адаптеров

Как упоминалось выше, OmniStudio использует процедуры интеграции и Data Mapper для простого сбора и трансформации внешних и внутренних данных Salesforce. Благодаря многочисленным функциям без кода, которые можно использовать, наборы данных сглаживаются и расширяются посредством взаимосвязей разных уровней.

Примечание к дорожной карте: В ближайшее время поток поддержит возможность обновления коллекций записей, а также управления иерархическими данными.

Flow, OmniStudio и LWC интегрируются в Apex, поэтому вы можете легко закрыть любые пробелы в выбранном решении. Например, если вам требуется фильтрация записей из LWC, вы всегда можете использовать проводной адаптер для Apex для создания сложных запросов SOQL. Если вас заинтересовала история на основе кликов, рассмотрите Flow или OmniStudio в качестве эффективных альтернатив контроллеру Apex для ваших серверных нужд.

Здесь возникает дополнительный вопрос: хотите ли вы немедленно подтвердить действия или отложить их в определенную часть формы. Это особенно актуально при использовании многостраничной формы. Поток упрощает объединение вводных данных из нескольких форм (окна потока) и их использование значительно позже в мастере (поток) для выполнения некоторых операций. На самом деле, мы рекомендуем проектировать потоки именно таким образом — выполнять действия в конце — в случае, если пользователь перескакивает между экранами, меняя ответы.

Транзакции и ограничения для управляющих являются образом жизни на Salesforce Platform. Если ваш сценарий использования достаточно прост, возможно, не так важно контролировать, в какой транзакции происходит определенная операция. Однако, существует несколько способов использования, когда вы хотите объединить несколько операций в одну транзакцию, а не выполнять их в нескольких транзакциях. Некоторые примеры:

• К откату или не к откату: Вот в чем вопрос. Например, форма создает несколько записей в фоновом режиме. Если третья запись не создана, должны ли первые две записи быть откаты? Если каждое из ваших действий не зависит друг от друга, выполните их отдельными транзакциями. Однако, если они зависимы и вы хотите, чтобы неудача одного из них также откатила другие, внедрите их в одну транзакцию. Если форма находится в потоке, можно использовать элемент отката в пути ошибки для отката транзакции и обеспечения целостности данных.
• Последнее влияние на контролирующие ограничения: Особенно, когда форма создает или обновляет запись, подумайте о последующих последствиях этой операции. Какие процессы, бизнес-правила, триггеры потока, триггеры Apex или другие элементы заказа на сохранение будут запущены на основе этого изменения записи? И как эти коллективные изменения влияют на ограничения губернатора, используемые в этой сделке? Если определенное изменение записи приведет к большому количеству изменений в нисходящем направлении, влияющих на ограничения, рекомендуем изолировать это изменение записи в собственную транзакцию.
• Пакетная обработка: Даже в контексте пользовательского интерфейса может понадобиться пакетировать несколько обновлений вместе. Например, многоэкранная форма повторяется в большой группе записей. Вместо выполнения обновления записи после каждого окна дождитесь сбора обновлений для всех записей, а потом отправьте один запрос на обновление всех записей.

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

При создании потока окон вы получаете значительный контроль над происходящим в данной транзакции. Окна и локальные действия действуют как границы между транзакциями. Ниже приведена общая информация об управлении транзакциями в архитектуре потока окон.

1. Конечный пользователь взаимодействует с окном, а потом нажимает «Далее».
2. Клиент публикует запрос в API с вводными данными.
3. API получает запрос, и открывается транзакция и подключение к базе данных. API потом вызывает механизм потока для вызова запроса.
4. Механизм потока берет на себя и следует соответствующему пути в определении потока, пока не попадет в узел окна или локального действия. Механизм потом возвращает сведения об этом узле в API.
5. API создает объект ответа, содержащий сведения о следующем окне для отображения, и возвращает этот объект клиенту. На этом этапе изменения базы данных фиксируются (подтверждение выполнения заказа), а подключение к базе данных и транзакция закрываются.
6. Клиент использует ответ API для отображения следующего окна для взаимодействия пользователя.
7. Повторите шаг 1.

Другими словами, отображает транзакции перерыва. В таком случае, все отложенные действия или DML будут зафиксированы, предыдущая транзакция будет закрыта и начнется новая транзакция.

Правильный дизайн — какие операции группируются в данную транзакцию — вы решаете сами. Рассмотрим несколько примеров.

Слева отображается поток, который собирает вводные данные в нескольких окнах, а потом выполняет несколько действий в одной транзакции.

Поток справа выполняет каждую операцию отдельной транзакцией.

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

В этом сценарии, если первые два элемента успешны, а последний не удался, первые две операции DML все равно создадут и обновят эти записи, а третья нет.

Используя элемент «Откат записей», можно обеспечить откат всей транзакции, если все три операции должны выполняться совместно, как показано в конечном потоке слева.

Дополнительную информацию см. в разделах Потоки в транзакциях и Пакетное выполнение потоков в транзакциях. Раздел «Автоматизированные» приложения Salesforce Well-Architected также более подробно рассматривается в разделе «Обработка данных».

Возможность управления транзакцией из LWC сводится к базовым службам, используемым LWC для выполнения операций. При использовании базового компонента формы записи Lightning основная операция (создание или обновление записи) выполняется в отдельной транзакции сразу после отправки формы.

В общем, применяются следующие правила:

• Каждый вызов API пользовательского интерфейса изолирован в отдельную транзакцию.
• Если вам нужно выполнить несколько операций в одной транзакции, отправьте вводные данные в серверную технологию, например, контроллер Apex или поток. Правила регулярных транзакций для этой технологии применяются.

Flow, OmniStudio и LWC поддерживают события платформы (для архитектуры под управлением событий) и интеграции API. Помимо настраиваемого кода Apex, декларативные механизмы интеграции API поддерживаются как Flow, так и OmniStudio.

Если вам нужно подключиться к боту Mulesoft API или RPA, используйте Mulesoft Services. Таким образом создается внешняя служба.

Внешние интеграции посредством Mulesoft API и ботов RPA

Если в API есть схема OpenAPI, создайте внешнюю службу.

Внешние интеграции в API со схемами OpenAPI

В противном случае, используйте функцию выноски HTTP в потоке или действие HTTP в OmniStudio. Выноска HTTP потока поддерживается внешними службами.

Внешние интеграции посредством HTTP

OmniStudio содержит богатый набор возможностей интеграции, которые могут вызывать внешние системы с помощью процедур интеграции и трансформировать данные посредством Data Mapper. (Дополнительную информацию см. в разделе «Влияние объекта»)

Вне зависимости от того, с помощью настраиваемого Apex или внешней службы, выноска есть выноска. Вам нужно знать следующее.

1. Выноска может занять много времени.
2. Когда выноска выполняется синхронно, она выполняется во время открытия транзакции базы данных.
3. Salesforce не позволяет держать транзакцию базы данных открытой при наличии отложенных операций базы данных.

Основным ограничением является опасность так называемых грязных транзакций, когда вы выполняете операцию создания, обновления или удаления, а потом, в той же транзакции, выполняете выноску. Эта схема не разрешена из-за рекомендации No3 выше, которая, конечно, существует из-за рекомендаций No1 и No2.

В потоке можно обойти это ограничение, нарушив транзакцию. Помните, что экраны и локальные действия возвращают контекст обозревателя, что нарушает транзакцию. Хотя экраны и локальные действия можно использовать при работе с внешними выносками, рекомендуем включить управление транзакциями в вызываемых расширенных параметрах. Управление транзакциями - это функция вызываемых действий, позволяющая автоматически завершить транзакцию до выполнения выноски. Управление транзакциями можно включить, выбрав «Всегда начинать новую транзакцию» в разделе «Дополнительно» вызываемого действия.

Дополнительные подробные рекомендации о выносках Apex, внешних службах и возможностях интеграции данных в целом см. в Руководстве архитектора по интеграции данных с Salesforce.

Динамические формы не поддерживают повторное использование. Каждая динамическая форма привязана к определенной странице записи Lightning для определенного объекта (хотя эту страницу записи Lightning можно назначить нескольким приложениям, профилям и так далее).

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

OmniStudio изначально создан для модульности. Карты данных, Omniscripts, FlexCards и процедуры интеграции созданы независимо и могут работать взаимозаменяемо. В дополнение, FlexCards можно создать в качестве компонентов LWC, встраиваемых в другие LWC, Omniscripts, страницы записей и сайты Experience Cloud.

Потоки окон, Omniscripts и LWC могут быть созданы для повторного использования и встроены в разные расположения, включительно с внешними сайтами и приложениями Lightning Out. При создании компонентных решений вы получаете дополнительные преимущества, например, адаптируемость и стабильность.

Все технологии, используемые для создания или обновления записи, придерживаются проверки на системном уровне – будь то классические правила проверки или настраиваемая проверка, встроенная в триггер Apex. Независимо от используемой технологии для выполнения изменения записи, каждое изменение выполняется в порядке сохранения. Это значит, что в дополнение к правилам проверки, изменение записи обрабатывается любым количеством потоков до или после сохранения, до или после триггеров, правил расширения, правил назначения и прочего. Если вы еще этого не сделали, обязательно добавьте закладки и ознакомьтесь с порядком выполнения Apex.

• Есть ли у вашей формы дополнительные требования помимо проверки на системном уровне?
• Вам нужно будет установить поля обязательными или доступными только для чтения в динамике формы?

Вводные данные в окне потока или на этапе Omniscript по своей природе не ограничены, поэтому сама форма не соответствует проверке на уровне системы, связанной с определенным объектом. Какие бы значения вы ни использовали для создания или обновления записей, они обрабатываются заказом на сохранение, то есть проходят проверку на системном уровне объекта. Обратите внимание, что не все компоненты потока окон поддерживают проверку ввода. Начиная с выпуска Summer ’24, остальные компоненты экрана, не поддерживающие проверку ввода: кнопки-переключатели, раскрывающийся список, раскрывающийся список со множественным выбором, группа флажков и поиск выбора.

Подобно макетам страниц, динамические формы позволяют настраивать обязательность и состояние только для чтения на уровне страницы. Однако, параметры системы не могут быть переопределены.

Поток предоставляет гибкость для настройки проверки на вводных данных формы. Хотя некоторые проверки выполняются в клиенте (например, пометка отсутствующих обязательных полей или несовместимых значений), ни одна из клиентских проверок не блокирует попытки перехода пользователя. Настоящая проверка выполняется на сервере. Когда пользователь нажимает «Далее», поток отправляет вводные данные на сервер для проверки. Если вводные данные возвращаются как недействительные, навигация блокируется и отображается соответствующая ошибка. Сервер проверяет вводные данные, проверяя:

1. Параметр обязательности ввода или совместимость введенного значения с основным типом данных.
2. Настраиваемая проверка этого ввода: Некоторые стандартные компоненты (Кнопка-флажок, Валюта, Дата, Дата/Время, Область подробного текста, Число, Пароль и Текст) поддерживают настраиваемую проверку на основе экрана. Добавьте логическое выражение формулы и сообщение об ошибке для отображения при несоответствии выражению формулы.
3. Настраиваемая проверка для основного компонента: При создании настраиваемого LWC для потока добавьте собственный код проверки к методу validate().

OmniStudio поддерживает обработку ошибок и проверки посредством действия «Задать ошибку» в сочетании с условными представлениями и компонентом службы сообщений.

Со стороны LWC большинство базовых компонентов выполняют собственные проверки клиента. Например, Lightning-форма записи учитывает системные требования, но не требования уровня страницы. Для настраиваемых компонентов можно Build Your Own механизмы проверки.

Поля, требующие ввода данных пользователями, должны отображаться в ваших формах раньше. При любой возможности проверьте вводные данные пользователя со стороны клиента перед отправкой форм. Дополнительные рекомендации по оптимизации форм см. в разделе «Рекомендации по формам в Salesforce Well-Architected - Engaging».

Безопасность вообще сложная тема, и когда речь заходит о построении форм, есть ряд рекомендаций, о которых вы могли даже не задумываться. На базовом уровне необходимо убедиться, что форма выполняется в правильном контексте и что у пользователей есть полномочия, необходимые для работы с основными данными. Но, кроме того, возможно, вам нужно принять дополнительные меры для удаления потенциально вредоносного кода или URL-адресов из полей обогащенного текста, запретить определенным пользователям доступ к форме или установить ограничения для типов областей, в которых администраторы могут потенциально встроить форму в будущем. Прежде чем выбрать инструмент, тщательно задокументируйте требования безопасности. Шаблон политики безопасности Salesforce содержит рекомендации по данному типу документации.

• Должна ли форма проверять доступ пользователя перед выполнением определенных операций?
• Следует ли очищать вводные данные пользователей?
• Хотите ли вы управлять доступом к форме?
• Хотите ли вы контролировать область внедрения формы?

Если что-то выполняется в контексте пользователя, Salesforce применяет ряд проверок доступа, включительно с проверкой безопасности поля, полномочий CRUD и доступа к записям на основе правил общего доступа вашей организации. Например, пользователи смогут запускать форму обновления обращений только при наличии возможности обновления обращений, соответствующей безопасности поля и доступа к соответствующей записи. Но что, если вы хотите, чтобы пользователи могли выполнять определенную операцию при использовании вашей формы, но не посредством другой формы или взаимодействия? Здесь появляется системный контекст.

Системный контекст — это способ повысить полномочия текущего пользователя на время сеанса, чтобы пользователю не требовался, например, доступ к объекту «Обращение» для успешного заполнения формы обновления обращения. Это особенно полезно для непроверенных сообществ. Вместо предоставления пользователям-гостям потенциально опасных способностей установите форму на выполнение в контексте системы.

Конечно, системный контекст - это палка о двух концах, и использовать ее следует только при необходимости. Если форма выполняется в системном контексте, каждая операция CRUD пропускает безопасность объекта и поля и общий доступ, а не только определенную операцию, которая вам нужна. Обратите внимание, что системный контекст не влияет на то, кого Salesforce считает исполнителем – имя, отображаемое в поле «Последнее изменение сделано». Исполнитель является текущим пользователем для каждой операции, выполняемой формой (например, обновление обращения), даже если форма выполняется в другом контексте.

Динамические формы, Omniscripts и LWC всегда выполняются в контексте пользователя, и это поведение невозможно переопределить.

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

• Если вы встраиваете компонент Lightning в поток, выполняемый в контексте системы, поток не переопределяет контекст компонента. Если вам нужно обойти проверки доступа пользователей, рекомендуем использовать поток для выполнения этих операций и передачи соответствующих данных в компонент Lightning или из него. Некоторые готовые компоненты (например, поиск) не могут работать в контексте системы.
• Если ваш поток вызывает действия Apex, нужно понимать еще несколько нюансов. Если классу Apex задано значение «Унаследованный общий доступ», он выполняется в системном контексте с общим доступом, независимо от того, на что настроен поток. Если класс не содержит четкого описания общего доступа, он выполняется в системном контексте без общего доступа, независимо от того, на что настроен поток. Если классу задано значение «Общий доступ» или «Без общего доступа», он делает это и переопределяет контекст потока.

Запрос записей в системном контексте с сайтами Experience Cloud:

Если вы выполняете поток в системном контексте на сайте Experience Cloud, особенно непроверенном, рекомендуем сохранять только определенные поля в элементах получения записей. При работе с потоком и передаче результатов элемента получения записей в подпоток, вызываемое действие или компонент Lightning, все поля из этого объекта можно проверить посредством инструментов разработчика обозревателя. Это может сделать поля доступными для нежелательных пользователей сайта Experience Cloud. Указав определенные поля в элементах получения записей, можно обеспечить открытие только нужных полей даже при включенном системном контексте.

Обратите внимание, что логика Omniscript выполняется со стороны клиента, что позволяет злоумышленникам изменять ожидаемое выполнение Omniscript и просматривать ответы на вызовы процедур интеграции, соотнесений данных и методов Apex посредством инструментов разработчика обозревателя. При использовании Omniscript рекомендуем выполнять бизнес- логику на сервере и внедрять правила проверки ввода для любых методов Apex, открытых посредством примечания @InvocableMethod.

Санитаризация вводных данных:

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

Рекомендации:

• Оставьте потоки выполняться в стандартном контексте, если вам не нужно повысить уровень доступа текущего пользователя к определенной операции.
• Избегайте выполнения потоков в системном контексте для пользователей-гостей из соображений безопасности. Создайте наборы полномочий с ограниченным доступом к полям, назначенные профилю пользователя-гостя сайта Experience Cloud.
• При запросе записей в потоках системного контекста на сайтах Experience Cloud сохраняйте только нужные поля в элементе получения записей или вызываемых действиях.
• Если поток выполняет разные операции, но не все из них требуют повышенного доступа, используйте подпотоки для изоляции операций, которые должны выполняться в контексте системы.
• Если вы планируете встроить форму во внешнюю веб- страницу, рекомендуем очищать вводные данные пользователя для удаления HTML посредством потока быстрого обновления поля или триггера Apex, если они будут соотнесены с полями обогащенного текста, чтобы предотвратить потенциальные фишинговые атаки от плохих исполнителей.

• Омнискрипты, FlexCards и LWC выполняются в контексте пользователя по умолчанию.
• LWC выполняются в контексте пользователя по умолчанию, а потоки - в контексте пользователя, но это можно переопределить в контроллере Apex.
• Операции, выполняемые посредством пользовательского интерфейса API, выполняются в контексте пользователя.
• Операции, выполняемые посредством контроллера Apex, зависят от этого класса. Чтобы выполнить эти операции в системном режиме, задайте классу Apex значение с общим доступом или без него.

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

Вы можете ограничить поток определенными профилями или наборами полномочий, подобно классу Apex или странице Visualforce. По умолчанию потоки не ограничены, то есть их может выполнять любой пользователь с полномочием «Выполнение потоков».

Если вы используете OmniStudio, настройте средство проверки полномочий Apex, чтобы обеспечить пользователям явный доступ к классу Apex, администрирующему удаленное действие, вызываемое из Omniscript, Flexcard, Classic Card или REST API.

• Обратите внимание, что проверка полномочий класса Apex включена по умолчанию для новых созданных сценариев. Однако они должны быть включены вручную для любых существующих сценариев
• Также обратите внимание, что проверки полномочий классов Apex применяются только к классам Apex. Рекомендуем также установить полномочия на уровне профиля для процедур интеграции и соотнесений данных.

Дополнительные сведения и рекомендации по полномочиям пользователя-гостя см. в разделе:

• Рекомендации по доступу к записям пользователей-гостей
• Разработка безопасных сайтов: Проверенные и пользователи-гости

Рекомендации:

• Если вы открываете поток пользователям-гостям, предоставьте профилю пользователя-гостя доступ только к нужным потокам. Хотя можно добавить «Выполнение потоков» в профиль пользователя-гостя, мы считаем это рискованной практикой.
• Будьте особенно осторожны с потоками, действующими в контексте системы. Мы настоятельно рекомендуем ограничить эти потоки определенными пользователями, поскольку у них меньше сдержек и противовесов для защиты данных.
• Убедитесь, что любой Omniscript, выполняющий Apex в сообществе пользователей-гостей, использует значение «с общим доступом» в определении класса Apex.
• В профиле пользователя-гостя назначьте только те классы Apex, которые должны быть доступны пользователям-гостям, иначе вы рискуете непреднамеренно открыть дополнительную бизнес-логику пользователям-гостям.

В LWC можно проверить назначения полномочий текущего пользователя, чтобы убедиться, что у него есть определенное стандартное или настраиваемое полномочие. Прямо из JavaScript можно импортировать полномочия Salesforce из модулей @salesforce/userPermission и @salesforce/customPermission. Или можно использовать Apex для проверки того же.

Веб- компоненты Lightning доступны в данном месте только при добавлении в качестве действительной цели. Например, компонент может быть доступен на страницах записей и недоступен в качестве элемента служебной панели.

После активации потока окон он доступен во всех местах, где поддерживаются потоки окон, вне зависимости от того, предполагалось ли, что он будет доступен везде или нет. При этом Flow Builder поддерживает несколько типов потоков с экранами. Хлебный тип - «Поток окон», но есть несколько других специализированных типов, ограниченных определенными расположениями. Например, мобильное приложение Field Service Mobile поддерживает только - вы догадались - мобильные потоки Field Service Mobile. То же самое касается потоков запросов связи, поддерживаемых только в Experience Cloud.

Вне зависимости от типа потока, отдельное лицо, создающее поток, не контролирует область, в которую можно встроить поток. Поток будет доступен во всех расположениях, поддерживаемых для данного типа потока.

Если вы используете Salesforce Industries, есть небольшая оговорка в отношении Omniscript: Хотя вы не можете указать цель для самого Omniscript, вы можете указать цель для FlexCards, которые вы хотите встроить в него.

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

• Какие типы взаимодействий или условия должны инициировать динамические ответы в вашей форме?
• Нужно ли выполнять операции вне экрана в фоновом режиме при заполнении формы?
• Вам нужно будет установить поля как видимые, обязательные, доступные только для чтения или отключенные или изменить форматирование на основе вводных данных формы?

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

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

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

Операции с данными Lightning

Доступность: Доступность можно динамически контролировать во всех инструментах создания форм. Динамические формы, Flow Builder и OmniStudio решают эту проблему посредством функций доступности компонентов. Таким образом, можно декларативно отображать или скрывать поля на основе других значений в форме, независимо от того, находится ли пользователь на мобильном устройстве или нет.

• С помощью динамических форм доступность можно контролировать на основе значений полей записи, записей, связанных посредством полей поиска и форм-фактора.
• С помощью потока можно основывать правило доступности на других вводных данных в экране, а также на других ресурсах, заполненных ранее в потоке, например, формулах или значениях из других записей.
  • Правила на основе устройства: С самого начала это не очевидно, но можно использовать формулу для отображения или скрытия определенного поля, когда пользователь находится на мобильном устройстве. Напишите формулу потока, проверяющую значение глобальной переменной $User.UIThemeDisplayed. Если значением является Theme4t, пользователь находится в мобильном приложении Salesforce.
  • Оценка других ресурсов: Ссылки на переменную вручную и формулы оцениваются только на сервере. Таким образом, какое бы значение ресурс ни имел при первом отображении окна, оно будет иметь значение до перехода к другому окну. При навигации среда выполнения потока отправляет запрос механизму потока (серверу) и возвращает последние значения переменных и формул, заданных вручную. Если вы ожидаете, что правило доступности будет обновляться при прохождении пользователем одного экрана (например, onblur), убедитесь, что вы ссылаетесь только на значения из других компонентов экрана.
• С помощью OmniStudio можно условно отобразить или скрыть компоненты, настроив свойство условного представления. Однако, добавить более одного свойства условного представления для ввода невозможно.

Состояния условного ввода: Если вам нужно динамически управлять другими свойствами, например, обязательным, отключенным или доступным только для чтения, у вас есть несколько вариантов. Как и ожидалось, LWC предоставляет полный реактивный контроль над состоянием ввода. С помощью реактивных компонентов потока окон можно динамически управлять атрибутами компонентов, например, «Только для чтения», «Отключено» и «Обязательно» для стандартных компонентов, поддерживающих его, в то время как OmniStudio поддерживает полный спектр атрибутов компонентов. Если ваши требования требуют, чтобы вам нужен поток, и компонент не поддерживает определенное состояние атрибута, можно создать встроенный LWC для достижения динамического состояния ввода.

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

Реактивные LWC в потоках окон: При создании LWC, которые могут реагировать и изменять другие компоненты в потоке окон, ознакомьтесь с данным руководством LWC по рекомендациям для потоков окон, чтобы обеспечить хорошую интеграцию компонентов в механизм среды выполнения потока и их корректную работу в будущем.

Теперь о настраиваемых событиях. Если некоторые вводные данные или вся форма должны быть связаны с чем-то другим на странице, LWC будет единственным вариантом.

• Для связи в одном дереве DOM используйте интерфейс CustomEvent.
• Для связи в DOM используйте службу сообщений Lightning.
• Если служба сообщений Lightning не поддерживается для целевого контейнера, используйте модуль public/ sub.

• Дополнительную информацию см. в разделах «Общение с событиями» и «Общение в DOM» в Руководстве разработки веб- компонентов Lightning.
• Для OmniStudio см. «Общение с Omniscript из веб- компонента Lightning».

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

• Насколько сложный стиль и CSS?
• Нужен ли настраиваемый стиль с пиксельным стилем или вы согласны со стандартными темами?

FlexCards - это единственный продукт, описанный в этом руководстве, который позволяет декларативно управлять стилем и макетом пользовательского интерфейса, создаваемого в инструменте напрямую, будь то поля и набивка, типография, цвета и т. д.

Динамические формы и потоки учитывают декларативные функции тем. Если вам нужен элемент управления, выходящий за рамки поддерживаемых Salesforce Themes, наборов фирменного стиля конструктора взаимодействий или сайтов LWR Experience Cloud, подумайте о программном решении.

Для групп, которым удобно работать с CSS, у вас есть несколько вариантов:

• Потоки и LWC наследуют стандартные маркеры дизайна.
• Omniscripts и FlexCards содержат поддержку настраиваемой системы проектирования: Newport.
• С помощью LWC можно написать собственные компоненты и полностью управлять HTML и CSS для них.

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

Напоминание: Компоненты Lightning можно встроить в потоки. Поэтому, если вам нужен пиксельный контроль над внешним видом формы, но вы хотите использовать другие преимущества потоков, например, модель навигации, вы можете иметь лучшее из двух миров. Аналогичный принцип применяется к Omniscripts и FlexCards.

Выбор правильного макета имеет решающее значение для создания оптимизированных форм, позволяющих быстро и эффективно вводить данные и повышающих целостность данных. Дополнительную информацию по данной теме см. в разделе «Salesforce Хорошо архитектурированные - формы».

• Как использовать макет формы для оптимизации взаимодействий пользователей?
• Как можно представить текущие данные пользователям, чтобы упростить их ввод в формы?

Динамические формы поддерживают двухстолбцовые макеты и могут быть разделены на отдельные разделы с полями. Эти разделы можно разместить в таких компонентах, как вкладки и аккордеоны, чтобы создать простые и упорядоченные макеты.

Потоки могут быть отображены посредством компонента «Раздел». С помощью разделов можно добавить до четырех столбцов и столько разделов, сколько нужно в окне потока. Компонент также реагирует на ширину экрана, поэтому может работать на экранах меньшего размера. Наконец, он предоставляет возможность применения условной доступности ко всему разделу, что упрощает пакетное применение доступности к нескольким полям в разделе. Разделы потока также поддерживают заголовки столбцов и предоставляют взаимодействие, похожее на «Гармошка», когда пользователи могут свернуть весь раздел, нажав на метку.

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

С помощью LWC можно использовать Lightning- record-[edit|view]-form и поддерживающее Lightning-[input| output]- field для управления макетом. Единственные ограничения макета — это ограничения из HTML/ CSS. Lightning- record-form учитывает конфигурацию раздела в связанном макете страницы. Например, если раздел является двухстолбцовым в макете страницы, он будет двухстолбцовым в этом компоненте.

Если форма будет доступна пользователям в разных регионах или говорящим на разных языках, необходимо убедиться, что используемый инструмент соответствует вашим требованиям к локализации. Дополнительные рекомендации и рекомендации см. в разделе «Salesforce Хорошо архитектура - Локализация». Если говорить конкретно о формах, то требования к локализации обычно предусматривают перевод элементов текста на другие языки.

• Ваша форма будет использоваться в нескольких странах или регионах?
• Нужно ли локализовать текст в вашей форме на других языках?

Если вы локализовали настраиваемые поля, эти переведенные метки учитываются в динамических формах. Динамические формы также учитывают настраиваемые метки, назначенные меткам и атрибутам компонентов в конструкторе приложений Lightning.

С помощью средства перевода поток поддерживает перевод меток, предназначенных для пользователя, для всех стандартных и настраиваемых компонентов окна. Метку, текст справки и сообщение об ошибке можно локализовать в следующих компонентах окна: Текст, область подробного текста, число, валюта, флажок, кнопки-переключатели, раскрывающийся список, раскрывающийся список со множественным выбором, группа флажков, пароль, дата и дата/время.

Нет встроенной поддержки перевода для готовых действий, например, «Отправка эл. почты» или «Опубликовать в Chatter». Однако, есть обходное решение! Если вы определите переведенные метки посредством настраиваемой метки, вы можете ссылаться на эту настраиваемую метку в действии или компоненте, настраивая ее в Flow Builder. Создайте формулу потока, которая ссылается на настраиваемую метку, и ссылайтесь на эту формулу в соответствующих областях потока.

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

Теперь о LWC. Определенные базовые компоненты автоматически наследуют переводы полей связанного объекта, текста справки и сообщений проверки, если они были настроены в средстве перевода (например: Lightning-record-form).

Если вам нужно ввести новые переводимые метки в код, настраиваемые метки остаются невоспетыми героями. Заявите нужную настраиваемую метку, а потом импортируйте ее в компонент из модуля @salesforce/label scoped.

Существует несколько комплексных инструментов автоматизации тестирования (например, Selenium), которые позволят моделировать взаимодействие пользователя с формой. Эти тесты можно написать для любого стандартного или настраиваемого пользовательского интерфейса, включительно со страницами Lightning и потоками окон. Однако важно отметить, что эти типы тестов не могут проверить результаты каждого выполняемого метода. Обязательно примите это во внимание при разработке требований к автоматизации тестирования пользовательского интерфейса.

• Нужно ли автоматическое тестирование формы?
• Какие типы тестов нужно выполнить?
• Какой уровень детализации нужен в автоматизации тестирования?

Ознакомьтесь с вашими требованиями к автоматизации тестирования пользовательского интерфейса.

Единичные тесты поддерживают более детализированную автоматизацию и проверку, работающую со стандартными системами и инструментами CI/CD отрасли, которые могут тестировать бизнес-логику компонентов, контроллер JavaScript и результаты. Используя только низкий код, вы не сможете самостоятельно создавать тесты, но Salesforce тщательно тестирует наши комплексные предложения.

Если методы компонента достаточно сложны, чтобы их можно было тестировать отдельно, поместите методы в специальные файлы JavaScript. Таким образом, их можно импортировать в LWC и в тест шута с помощью import { sort } from 'c/utils';.

См. раздел «Автоматизация тестирования пользовательского интерфейса в Salesforce» для сравнения разных вариантов создания комплексной автоматизации в Salesforce. Включены рекомендации по использованию решения без кода из ISV, Build Your Own настраиваемого решения автоматизации тестирования или использованию инфраструктуры тестирования с открытым исходным кодом, например, Selenium WebDriver или WebdriverIO. Эти решения действительны для любого взаимодействия пользовательского интерфейса в Salesforce, будь то динамическая форма на странице Lightning, поток окон на служебной панели или LWC в потоке в быстром действии.

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

• Нужно ли отслеживать использование формы?
• Какие КПЭ определят эффективность использования формы?

Если вам нужно отслеживать общее использование и принятие формы, начните с инструментов с низким кодом. Динамические формы и потоки окон отслеживаются посредством готовых типов настраиваемых отчетов, хотя вы получите больше детализации в отчетах по отслеживанию потоков окон. Если вам нужно отслеживать использование LWC, готовность зависит от того, где вы используете этот LWC. Если оно находится на странице Lightning, все, что доступно для отслеживания использования страницы Lightning, применяется к вашему LWC. Та же история относится к LWC, встроенным в потоки.

Сами динамические формы недоступны для отслеживания, хотя вы можете отслеживать использование родительской страницы Lightning посредством объектов использования Lightning. Чтобы отслеживать стандартные страницы Lightning, используйте тип настраиваемого отчета «Пользователи с использованием Lightning по показателям страниц». Для получения аналогичной информации на настраиваемых страницах Lightning используйте тип настраиваемого отчета «Пользователи с использованием Lightning по FlexiPage Metrics».

Для отслеживания принятия определенной формы (не только страницы, на которой она расположена) поток предоставляет вам покрытие. Используйте «Пример отчета по потокам: Потоки экрана» для ответа на следующие вопросы:

• Какой уровень заполнения для этой формы? Это хорошо принято?
• Сколько времени нужно пользователям для заполнения этой формы?
• На каком экране пользователи проводят больше времени?
• Как часто пользователи переходят назад?
• Как часто происходят ошибки?

Если стандартный отчет не соответствует вашим потребностям, клонируйте его, чтобы внести собственные изменения или Build Your Own с нуля, используя тип отчета «Потоки окон».

Если вы используете среду выполнения Omniscript на основе пакета, можно использовать OmniStudio для службы отслеживания Vlocity. Эта служба отслеживает события любого типа. Например, можно отслеживать время, необходимое для выполнения этапов в Omniscript для определения усовершенствований процесса. Это в дорожной карте рабочей группы OmniStudio для поддержки этой службы в Standard OmniStudio.

Чтобы отслеживать то же самое для LWC, не встроенного в поток окон, Omniscript или страницу Lightning, не существует готового варианта. Настраиваемое решение можно создать с помощью Apex.

Когда вам нужно развернуть решение в более высоких средах для тестирования или развертывания в производстве, возможно, вы привыкнете использовать для этого наборы изменений или DevOps Center. Динамические формы, потоки и LWC полностью поддерживаются в этих параметрах развертывания. OmniStudio требует отдельного инструмента: IDX Workbench.

• Как вы планируете развертывать форму?
• Будет ли ваша форма распространена среди нескольких организаций Salesforce?

Если вы являетесь ISV или партнером, который планирует пакетировать ваше решение для распространения в AppExchange, рекомендуем сначала посмотреть динамические формы, потоки и LWC. OmniStudio не поддерживает пакетирование.

Это руководство поможет вам понять, какие функции и уровень настройки возможны с динамическими формами, потоками окон, OmniStudio и LWC. На высоком уровне:

• LWC - это самый настраиваемый и надежный вариант создания формы, но у него меньше всего ограждений. Вы можете создать компонент, обеспечивающий безопасность и масштабируемость.
• Динамические формы являются наименее гибкими, но существует гораздо меньше возможностей для ошибок.
• Поток и OmniStudio расположены где-то посередине – более мощно, чем динамические формы, но не совсем на уровне LWC. Кроме того, у них меньше ограждений, чем у динамических форм, но их сложнее взломать, чем настраиваемый код.

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

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

Специализированные навыки: Какой объем знаний у вашей команды в сравниваемых инструментах? Сколько создателей хорошо знакомы с LWC или JavaScript? Как насчёт создателей, которые являются экспертами в Flow Builder или выразили заинтересованность в том, чтобы опустить пальцы? В общем, динамические формы и навыки потока более достижимы для более широкой группы людей, создающих формы. Динамические формы являются самым декларативным инструментом создания форм и всегда будут легче изучаться, чем поток. При этом группа, работающая с потоками, стремится снизить планку как можно ниже. С точки зрения сложности, OmniStudio находится где-то между Flow и LWC и предлагает значительные суперспособности создания форм.

Delegation of Delivery: Если некоторые из ваших требований требуют LWC, это не значит, что все ваше решение должно быть создано с помощью LWC. Подумайте, как создать решение по модулю, чтобы детали, требующие LWC, были закодированы, а детали, не созданные в низкокодированном решении. Это позволяет повысить эффективность многопрофильной рабочей группы и обеспечить решение задач, соответствующих их специализации.

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

Обслуживаемость и долгосрочная собственность: При наличии многоэтапной формы рекомендуем начать с потока или сочетания потока и LWC. Если у вас есть рабочая группа с низким кодом, обслуживающая решение, подумайте, как сделать решение максимально настраиваемым и расширяемым для этой аудитории. Какой бы инструмент вы ни выбрали, систематизируйте решение по составным единицам для улучшения обслуживания и стабильности.

В дальнейшем рекомендуемый способ настройки страниц сведений о записях - динамические формы в конструкторе приложений Lightning с помощью страниц Lightning. Мы давно не расширяли макеты страниц, и эта тенденция сохранится. Вот почему:

• Динамические формы более гибкие – поля и разделы можно размещать где угодно прямо в конструкторе приложений Lightning, где можно воспользоваться разделами, вкладками и аккордеонами. И так же, как и с компонентами на странице Lightning, можно управлять доступностью полей и разделов, не определяя несколько макетов страниц или типов записей.
• С помощью компонентов «Гармошка» и «Вкладка» можно ограничить объем изначально отображаемых полей. Угадайте, что это значит? Более быстрое время загрузки страницы.
• Управление макетами упрощено на страницах Lightning, так как управлять всем содержимым страниц можно в конструкторе приложений Lightning — будь то содержимое страницы или пользователи, имеющие доступ к странице. Нет необходимости вносить обновления в макет страницы, чтобы изменения произошли на странице Lightning. Не говоря уже о том, что с помощью правил доступности больше не нужно создавать несколько страниц (или макетов страниц) для управления просмотром полей. А это также значит, что пользователям нужно только назначить страницу Lightning, а не назначать и страницу Lightning, и макет страницы.

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

Любые рекомендации по производительности, связанные с динамическими формами, потоками окон, OmniStudio и LWC, сосредоточены на том, на какой инфраструктуре находятся сами эти технологии. Те, что базируются в LWC (кроме, конечно, LWC), будут превосходить те, что базируются в Aura. Инфраструктура LWC предлагает лучшую производительность, поскольку базовые функции внедряются нативно в веб-двигатели, а не в JavaScript посредством абстракций инфраструктуры. Если вы не знакомы, ознакомьтесь с сообщением блога.

Еще в 2019 году мы провели тематическое исследование, сравнивая производительность тех же функций в Aura и в LWC. В результате преобразования DreamHouse из Aura в LWC не только опыт разработки был в гораздо большей степени согласован с текущими стандартами и схемами разработки веб-сайта, но и был достигнут значительный рост производительности. Лабораторные измерения показали прирост в диапазоне от 2,4% до 24,7% для холодного кэша и прирост в диапазоне от 31,83% до 63,32% для теплого кэша на тех же двух страницах.

Итак, какую инфраструктуру используют технологии форм? Другими словами, какая форма технологий выигрывает от такой превосходной производительности?

• Динамические формы, интегрированные в метаданные страниц Lightning, созданы на основе, использующей стек LWC, что позволит нам внедрить некоторые давно востребованные функции. В качестве бонуса производительности динамические формы используют постепенный рендеринг, что приводит к улучшению времени загрузки страниц для страниц с большим количеством полей.
• Потоки окон созданы на основе LWC с большинством готовых компонентов, преобразованных в LWC, за исключением двух готовых компонентов: Загрузка файла и изображение. Хотя рабочая группа потока преобразовала клиент среды выполнения потока в LWC, а также большинство его компонентов, клиентам все равно нужно преобразовать компоненты экрана Aura в LWC. Кроме того, Salesforce поддерживает только компоненты LWC в новой инфраструктуре реактивных компонентов в потоках окон. Существует отличный модуль Trailhead, который объясняет, как это сделать: Веб-компоненты Lightning для разработчиков Aura. Само собой разумеется: Если вы планируете создать настраиваемый компонент для потока окон или любого другого контейнера, всегда переходите в LWC.
• Существует несколько доступных версий OmniStudio. Если вы являетесь давним клиентом, возможно, вы используете Angular. Мы рекомендуем всем новым клиентам начать с Omniscripts на основе LWC и FlexCards, а существующим клиентам мигрировать из Angular.
• LWC создан на основе ... LWC, конечно. Это халява.

Архитектору важно иметь четкое понимание всех доступных вариантов и способов их применения в конкретном сценарии использования. Для создания форм в Salesforce варианты варьируются от низкокодовых (использование динамических форм в конструкторе приложений Lightning, потоков окон в Flow Builder и Omniscripts в OmniStudio) до прокодированных (использование инфраструктуры LWC), с комбинацией потоков окон или Omniscripts и LWC посередине. Помните об этом руководстве и используйте его в качестве ссылки при планировании создания или изменения дизайна форм в Salesforce. Если вам нужны рекомендации по созданию упрощенных и полезных форм, обратитесь к Salesforce Well-Architected: Занимательно.

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