Строительные формы

Существует несколько вариантов создания форм на платформе Agentforce 360, и они охватывают континуум от низкокодовых до прокодированных подходов. На одном конце континуума динамические формы в конструкторе приложений Lightning и потоки окон в Flow Builder можно использовать для решений с низким кодом. С другой стороны, инфраструктура веб-компонента Lightning (LWC) используется для прокодированных решений. В рамках континуума инструменты можно смешивать несколькими способами посредством потоков окон, расширенных LWC и формами, ориентированными на клиента, созданными посредством Omnistudio.

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

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

• Если вам нужно создать, создать или изменить форму для одного объекта, используйте Lightning Pages и динамические формы. Это самый простой способ создания форм на платформе Agentforce 360. Он также предоставляет дополнительные функции (например, управление доступностью поля).

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

• Если вам нужна дополнительная логика или действия для поддержки формы, используйте поток окон, Omnistudio или LWC. Каждый из этих инструментов предлагает разные способы улучшения решения, позволяя ему выйти за рамки создания или редактирования отдельной записи. В данном случае термин «больше» может обозначать расширенную логику (например, ответвление или итерация) или такие действия, как интеграция с внешними системами, отправка сообщений эл. почты или всплывающие уведомления в мобильное приложение пользователя.

• Если у вас сложные требования к UX или вам нужно динамически управлять не только доступностью пользовательского интерфейса, используйте LWC или Omniscript. Для требований, которым может соответствовать использование тем и макетов на основе столбцов, можно создать формы напрямую в низкокодовом конструкторе. Однако, детализированный контроль над стилем формы требует гибкости LWC. Если вы являетесь клиентом отраслей и вам нужен пиксельный фирменный стиль или у вас есть сложные иерархические данные, используйте Omnistudio, позволяющий создавать формы потребительского уровня, которые могут обрабатывать сложную бизнес-логику и трансформации данных.

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

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

Следующие инструменты обычно используются для внедрения и расширения взаимодействий форм.

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

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

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

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

• Доступно: Инструмент/функция работает с основными рекомендациями.

• Недоступно: Добавление поддержки в течение следующих 12 месяцев не планируется.

• Не идеально: Этот инструмент/функция может работать, но не является оптимальным инструментом.

• Не применяется: Инструмент не применяется к конкретному сценарию использования.

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

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

• Нужен ли один экран или пользователю нужно переходить между несколькими экранами для выполнения задачи?

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

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

• Можно ли отобразить панель навигации внизу формы? Если взаимодействие навигации потока окон и мультискрипта предоставляет нежелательный UX, склонитесь к LWC.

• Что должно происходить за формой? Если вам нужно, чтобы поведение настраивалось администратором, используйте поток. Для сложных взаимосвязей с несколькими объектами используйте Omniscript или LWC.

Если вы выберете Flow или Omnistudio, возможно, вам также потребуется создать LWC для достижения правильного UX. Если вы уже создаете LWC для правильной стилизации формы, подумайте о необходимости встраивания этого компонента в поток.

Навигация в стиле мастера

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

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

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

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

• Потребуется ли пользователям доступ к форме посредством ПК, мобильного устройства или и того, и другого?

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

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

• Требуется ли доступ к форме на внешнем веб-сайте?

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

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

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

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

Компоненты LWC также могут запускать потоки посредством компонента Lightning-Flow.

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

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

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

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

• Нужно ли использовать значения из связанной записи?

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

• Требуется ли интеграция с внешними системами?

• Каковы ваши требования к многоразовости и модульности?

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

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

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

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

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

Ниже указаны некоторые примеры:

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

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

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

  • Как эти коллективные изменения влияют на регуляторные ограничения, которые расходуются в рамках этой сделки?

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

• Пакетная обработка: Возможно, вам потребуется пакетное пакетное обновление нескольких пакетов (даже в контексте пользовательского интерфейса). Например, многоэкранная форма повторяется в большой группе записей. Вместо выполнения обновления записи после каждого окна (дождитесь сбора обновлений для всех записей) и отправьте один запрос на обновление всех записей.

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

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

1. Конечный пользователь взаимодействует с окном, а потом нажимает «Далее».

2. Клиент публикует запрос ввода в API.

3. API получает запрос и открывает транзакцию и подключение к базе данных. Потом API вызывает механизм потока для вызова запроса.

4. Механизм потока берет на себя и следует соответствующему пути в определении потока, пока не попадет в экран или локальный узел действия. Потом механизм возвращает сведения об этом узле в API.

5. API создает объект ответа, содержащий сведения о следующем окне для отображения, и возвращает этот объект клиенту. На этом этапе изменения базы данных фиксируются (в соответствии с выполнением заказа сохранения), а подключение к базе данных и транзакция закрываются.

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

7. Начните с этапа 1 и повторите процесс.

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

Ниже указаны некоторые примеры:

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

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

Примечание: Дополнительную информацию см. в разделах «Потоки в транзакциях» и «Пакетное выполнение потоков в транзакциях».

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

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

• Каждый вызов API пользовательского интерфейса изолирован в собственной транзакции.

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

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

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

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

Во всех других случаях используйте функцию выноски HTTP (поддерживается внешними службами) в потоке или Действие HTTP в Omnistudio.

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

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

Вам нужно знать следующее.

• Обработка выноски может занять значительное время.

• Когда выноска выполняется синхронно, она выполняется во время открытия транзакции базы данных.

• Salesforce не позволяет держать транзакцию базы данных открытой при наличии отложенных операций базы данных.

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

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

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

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

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

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

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

Примечание: Просмотрите и добавьте в закладки порядок выполнения Apex.

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

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

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

Примечание: Не все компоненты потока окон поддерживают проверку ввода.

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

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

Сервер проверяет вводные данные, проверяя:

• Параметр требования ввода или совместимость введенного значения с основным типом данных.

• Настраиваемая проверка вводных данных. Вам нужно ввести выражение логической формулы и сообщение об ошибке для отображения при несоответствии выражению формулы.

• Настраиваемая проверка основного компонента. Если вы создаете настраиваемый LWC для потока, необходимо добавить собственный код проверки к методу validate().

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

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

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

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

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

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

• Нужно ли выполнять операции вне экрана (фоновые) во время заполнения формы?

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

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

Выполнение внеэкранных операций над данными

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

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

Доступность

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

• Динамические формы управляют доступностью на основе значений полей записи, полей поиска и форм-фактора.

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

  • Правила на основе устройства: Это может быть неочевидно с самого начала, но можно использовать формулу для отображения или скрытия определенного поля, когда пользователь находится на мобильном устройстве. Напишите формулу потока, проверяющую значение глобальной переменной $User.UIThemeDisplayed. Если значение Theme4t, пользователь заполняет форму посредством мобильного приложения Salesforce.

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

• С помощью Omnistudio можно условно показать или скрыть компоненты, настроив свойство «Условное представление». Однако, нельзя добавить более одного свойства условного представления для ввода.

Состояния условного ввода

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

При необходимости динамического управления другими свойствами (например, обязательное или только для чтения) используйте LWC в краткосрочной перспективе, поскольку у вас есть полный контроль. Это особенно актуально, если у вас есть индивидуальные требования к способу обработки onblur или onclic.

Реактивные LWC в потоках окон

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

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

• Для связи в одном дереве DOM используйте интерфейс CustomEvent.

• Для связи в DOM используйте службу сообщений Lightning.

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

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

• Для Omnistudio см. раздел «Общение с Omniscript из веб- компонента Lightning».

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

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

Переопределения стиля предназначены для локализированных визуальных исключений (например, выделение окна подтверждения или выделение определенного призыва к действию (CTA); они не являются полной системой стиля. Они не предоставляют управления на уровне CSS и не предназначены для повторного использования в окнах или потоках.

С архитектурной точки зрения стилистика должна соответствовать следующему прецедентному порядку:

1. Темы и фирменный стиль: Lightning Themes, наборы фирменного стиля конструктора взаимодействий или тематика сайта LWR

2. Переопределения стиля потока: Целевая корректировка экрана или компонента

3. Настраиваемые компоненты (LWC): когда требуется пиксельное управление или многоразовые схемы проектирования

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

• Насколько сложный стиль и CSS?

• Вам нужен настраиваемый стиль или стандартные темы?

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

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

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

• Потоки и LWC наследуют стандартные маркеры дизайна.

• Омнискрипты и FlexCards поддерживают настраиваемую систему проектирования посредством Newport.

• С помощью LWC можно написать собственные компоненты и полностью контролировать их HTML и CSS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поток поддерживает перевод меток пользователя для всех стандартных и настраиваемых компонентов окна посредством средства перевода.

Метки, текст справки и сообщения об ошибках можно локализовать в следующих компонентах окна:

• Текст
• Область подробного текста
• Число
• Валюта
• Кнопка-флажок
• Кнопки-переключатели
• Раскрывающийся список
• Раскрывающийся список со множественным выбором
• Пароль группы флажков
• Дата
• Дата/время

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

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

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

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

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

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

Обязательно тщательно задокументируйте требования безопасности перед выбором инструмента. Дополнительные рекомендации по данному типу документации см. в разделе «Шаблон политики безопасности Salesforce».

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

• Следует ли очищать вводные данные пользователей?

• Хотите ли вы управлять доступом к форме?

• Хотите ли вы контролировать область внедрения формы?

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

Что происходит, если вы хотите, чтобы пользователи могли выполнять определенную операцию при использовании вашей формы, но не посредством другой формы или взаимодействия? Здесь появляется системный контекст!

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

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

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

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

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

• Если ваш поток вызывает действия Apex, в этом случае учитываются другие нюансы.

  • Если классу Apex задано значение «Унаследованный общий доступ», он будет выполняться в системном контексте с общим доступом, независимо от способа установки потока.

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

  • Если класс установлен на «с общим доступом» или «без общего доступа», он переопределяет контекст потока.

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

Если вы выполняете поток в системном контексте на сайте Experience Cloud (особенно если он не проверен), сохраните только определенные поля в элементах «Получение записей». При работе с потоком и передаче результатов элемента «Получение записей» в подпоток, вызываемое действие или компонент Lightning, все поля из этого объекта могут быть проверены инструментами разработчика обозревателя. Несмотря на ваши намерения, это может сделать поля доступными пользователям Experience Cloud. Чтобы обеспечить открытие только правильных полей при включении системного контекста, укажите эти конкретные поля в элементах «Получение записей».

Примечание: Логика мультискрипта выполняется со стороны клиента, что даёт возможность злоумышленникам изменять ожидаемое выполнение мультискрипта и просматривать ответы на вызовы процедур интеграции, соотнесений данных и методов 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. Рекомендуем также установить полномочия на уровне профиля для процедур интеграции и соотнесений данных.

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

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

• Убедитесь, что любой Omniscript, выполняющий Apex в сообществе пользователей-гостей, использует общий доступ, указанный в определении класса Apex.

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

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

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

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

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

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

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

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

• Нужно ли автоматическое тестирование форм?

• Какие типы тестов вы планируете выполнить?

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

Учитывать требования к автоматизации тестирования пользовательского интерфейса

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

Если методы вашего компонента сложные, вы можете отправить текстовые сообщения отдельно, разместив методы в специальных файлах JavaScript. Это позволяет импортировать их в LWC, а потом в тест Jest (например, импорт { sort } из 'c/ Utils';).

Вы можете использовать решение без кода из ISV, создать настраиваемое решение автоматизации тестирования или использовать инфраструктуру тестов с открытым исходным кодом (например, 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, что помогает определить улучшения процесса).

Примечание: Готового варианта отслеживания LWC, не встроенного в поток окон, Omniscript или страницу Lightning, нет, но настраиваемое решение можно создать с помощью Apex.

Возможно, вы знакомы с использованием наборов изменений или DevOps Center для развертывания решения в тестовых средах или в производственной среде. Эти параметры развертывания полностью поддерживают динамические формы, потоки и LWC. Однако, Omnistudio требует отдельного инструмента, Средство обработки IDX.

• Как вы планируете развертывать форму?

• Нужно ли распространять форму в нескольких организациях Salesforce?

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

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

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

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

• Поток и Omnistudio немного падают в середине. Они более мощные, чем динамические формы, но не совсем соответствуют уровню LWC. Однако, у них меньше ограждений, чем у динамических форм, и их сложнее взломать, чем настраиваемый код.

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

• Когда вы сравниваете инструменты, важно оценить, сколько опыта у вашей команды в отношении каждого инструмента?
• Сколько разработчиков хорошо разбираются в LWC или JavaScript?
• Есть ли в вашей команде разработчики, которые являются экспертами в Flow Builder или которые выразили заинтересованность в получении дополнительной информации?

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

Delegation доставки

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

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

Долгосрочная собственность и ремонтопригодность

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

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

Итак, как использовать преимущества производительности для технологий форм в Salesforce? Рассмотрим подробнее.

• Динамические формы (интегрированные в метаданные страницы Lightning) построены на основе основы LWC-stack, что позволяет реализовать несколько долгожданных функций. В качестве дополнительного бонуса производительности динамические формы используют постепенный рендеринг, что улучшает время загрузки страниц с большим количеством полей.

• Потоки окон созданы на основе LWC. Большинство готовых компонентов преобразованы в LWC, за исключением компонентов загрузки файлов и изображений. Хотя рабочая группа потока преобразовала клиент среды выполнения потока в LWC (и большинство его компонентов), клиентам нужно преобразовать компоненты экрана Aura в LWC. Помните, что Salesforce поддерживает только компоненты LWC в инфраструктуре реактивных компонентов в потоках окон. Дополнительную информацию см. в модуле Lightning Web Components for Aura Developer Trailhead. Если вы планируете создать настраиваемый компонент для потока окон (или любого другого контейнера), выберите LWC!

• Существует несколько доступных версий Omnistudio. Если вы являетесь давним клиентом, возможно, вы используете Угловой. Мы рекомендуем всем новым клиентам использовать Omniscripts и FlexCards на основе LWC. Мы также рекомендуем существующим клиентам мигрировать из Angular.

• LWC создан на основе LWC.