--- schema_version: "1" id: f7cbb80099f1f0ee0fbf446e378aa55d0d4235e93d31dce58d3e1c898e4344a9 title: Formularios de construcción collection: architect version: current locale: es-mx portal_url: https://docs.salesforce.com/architect/current/es-mx/decision-guides/guides/build-forms.md canonical_url: https://architect.salesforce.com/docs/architect/es-mx/decision-guides/guide/build-forms.html source_site: architect.salesforce.com content_type: documentation content_hash: ab3e877e468e8c12672d1e5b7ebd10fac4d5f369557d1be5e9cb6cd10cc90111 products: - Guías de decisiones - Architect Site Content Repo updated_at: 2026-03-01T00:00:00Z --- # Formularios de construcción Existen múltiples opciones para la creación de formularios en Agentforce 360 Platform, y abarcan un continuo desde enfoques de código bajo a pro-código. En un extremo del continuo, Formularios dinámicos en Lightning App Builder y flujos de pantalla en Flow Builder se pueden utilizar para soluciones de código bajo. Por otro lado, el marco de trabajo Componente web Lightning (LWC) se utiliza para soluciones de procódigo. Dentro del continuo, las herramientas se pueden combinar de varias formas utilizando flujos de pantalla ampliados por LWC y formularios de cara al cliente que se crean utilizando OmniStudio. ## Descripción general de guía Esta guía presenta un marco de decisiones y directrices sobre la creación de formularios para soluciones de interfaz de usuario. Específicamente, utiliza una docena de puntos de decisión de tiempo de ejecución y no funcionales para seleccionar correctamente la mejor tecnología para un caso de uso concreto. ## Comida para llevar - **Cuando cree/modifique/vea formatos para páginas Lightning, utilice Formularios dinámicos.** En adelante, recomendamos utilizar _Formularios dinámicos_ en _Lightning App Builder_ para configurar páginas de detalles de registros. - **Si necesita crear, crear o modificar un formulario para un objeto, utilice _Lightning Pages_ y _Dynamic Forms_.** Esta es la forma más sencilla de crear formularios en Agentforce 360 Platform. También proporciona funciones adicionales (por ejemplo, control de visibilidad de campo). - **Si está creando un formulario de varias páginas o un asistente y no tiene requisitos estrictos de marca o UX, utilice un Flujo de pantalla.** Los flujos de pantalla proporcionan un marco de trabajo de navegación lineal para orquestar múltiples formularios. Puede utilizar LWC para construir su propio marco de trabajo para navegar entre formularios, pero recomendamos permitir que Flow haga el trabajo de modo que pueda centrarse en los formularios en sí en vez de centrarse en el estado del formulario. - **Si necesita lógica o acciones adicionales para admitir el formulario, utilice un Flujo de pantalla, OmniStudio o LWC.** Cada una de estas herramientas ofrece diferentes formas de mejorar su solución permitiéndole ampliarse más allá de la creación o modificación de un único registro. En esta instancia, el término _más_ puede hacer referencia a lógica avanzada (por ejemplo, bifurcación o iteración), o puede hacer referencia a acciones como la integración con sistemas externos, el envío de emails o el envío de notificaciones a la aplicación móvil de un usuario. - **Si tiene requisitos de UX sofisticados o si necesita gestionar de forma dinámica más de visibilidad de la interfaz de usuario, utilice LWC u OmniScript.** Para requisitos que se pueden cumplir utilizando formatos basados en tema y columna, puede crear sus formularios directamente en un generador de código bajo. Sin embargo, el control granular sobre el estilo de su formulario requiere la flexibilidad de LWC. Si es un cliente de Industries (y necesita una marca perfecta para los píxeles o tiene datos jerárquicos complejos), utilice Omnistudio, que le permite crear formularios de nivel de consumidor que pueden gestionar transformaciones de datos y lógica de negocio complejas. - **Si necesita implementar la automatización de pruebas, utilice LWC.** Puede redactar pruebas de unidad para cualquier LWC, independientemente de dónde lo integre. Esto proporciona la capacidad de crear una estrategia de prueba más sólida, que puede incluir pruebas masivas con múltiples registros, así como pruebas negativas. - **No está obligado por “cualquiera/o” decisiones.** Puede combinar múltiples opciones para alcanzar la mejor solución para sus casos de uso (por ejemplo, si necesita el sistema de navegación integrado de Flow y la flexibilidad de estilo completa que ofrece LWC, puede utilizarlas conjuntamente). ## Herramientas en ámbito Las siguientes herramientas se utilizan habitualmente para implementar y ampliar experiencias de formulario. ### Descripciones de herramientas
Formularios dinámicos Formularios dinámicos en Salesforce Lightning App Builder desglosa componentes Detalle de registro monolíticos en secciones y campos configurables individuales. Esta función permite a los administradores crear páginas flexibles y de alto desempeño colocando campos en cualquier parte y utilizando reglas de visibilidad para mostrar u ocultar componentes basándose en perfil de usuario, dispositivo o datos, lo que ayuda a reducir la aglomeración de páginas.
Flujo de pantalla Un Flujo de pantalla de Salesforce es una herramienta de automatización interactiva dentro de Flow Builder que requiere la entrada del usuario para pasar por procesos de negocio personalizados paso a paso. A diferencia de los flujos en segundo plano automatizados, los flujos de pantalla proporcionan una interfaz de usuario similar a la del asistente para recopilar datos, mostrar información o realizar acciones a través de Páginas Lightning, botones o aplicaciones personalizadas sin escribir código.
Omnistudio Salesforce Omnistudio es un conjunto de herramientas de código bajo diseñado para crear rápidamente experiencias digitales guiadas específicas de la industria y procesos de negocio complejos. Permite a los desarrolladores crear interfaces de usuario perfectas para píxeles (por ejemplo, flujos de trabajo guiados y tableros dinámicos) utilizando componentes de arrastrar y soltar como Flexcards y OmniScripts. Con OmniStudio, puede crear LWC de forma declarativa.
Componentes web Lightning Componentes web Lightning de Salesforce son elementos HTML personalizados ligeros que se crean utilizando HTML, CSS y JavaScript moderno, y están diseñados para ejecutarse de forma nativa en navegadores para un desempeño superior de la interfaz de usuario de Salesforce. Permiten a los desarrolladores crear interfaces de usuario personalizadas que coexisten con componentes Aura, lo que aumenta el desarrollo a través de estándares de la industria y un ecosistema de componentes detallado.
### Conjuntos de herramientas y requisitos de licencia Esta tabla describe las herramientas disponibles para la creación de formularios a través de Salesforce, junto con sus habilidades requeridas y consideraciones de licencia. **Nota:** Profundizaremos en las funciones específicas compatibles con cada herramienta, cómo elegir entre herramientas basadas en clics y herramientas basadas en código, y cuándo combinarlas en una sección posterior.
Configuración Requisitos de licencia adicionales
Formularios dinámicos Código bajo Ninguna
Flujo de pantalla Código bajo Ninguna
Omnistudio Código bajo + Código profesional Paquete Industries
Flujo de pantalla más componentes web Lightning Código bajo + Código profesional Ninguna
Componentes web Lightning Código Pro Ninguna
## Puntos de decisión Existen varios puntos de decisión a tener en cuenta cuando realice selecciones de productos y herramientas. Esta tabla describe varios puntos de decisión y proporciona directrices de alto nivel.
Punto de decisión Directrices
Categorías de casos de uso de tiempo de ejecución
Ámbito de formulario y navegación Determine si todos los campos de su formulario se ajustarán lógicamente a una única pantalla o si los usuarios necesitan poder navegar entre múltiples pantallas.
Ubicación Identifique la(s) ubicación(es) donde desea incrustar el formulario, que puede ir desde una aplicación de Salesforce hasta una aplicación móvil y un sitio web externo.
Controlador Identifique las acciones o la lógica que se deben realizar en segundo plano mientras los usuarios interactúan con su formulario, incluyendo transformaciones de datos e integraciones con sistemas externos.
Validación Determine si tiene requisitos de validación de entrada adicionales que vayan más allá de la validación a nivel del sistema estándar que proporciona Salesforce.
Diseño de interacciones Identifique los tipos de interacciones o condiciones que deben desencadenar respuestas dinámicas en su formulario.
Estilo Determine el nivel de sofisticación necesario para su estilo y requisitos CSS deseados.
Formato Identifique los requisitos de formato de su formulario (por ejemplo, el número requerido de columnas, fichas y acordeones) y la capacidad de mostrar bloques de datos repetitivos.
Traducción Determine si su formulario debe estar traducido para otros idiomas.
Consideraciones no funcionales
Seguridad Determine si su formulario debe comprobar el acceso del usuario antes de realizar ciertas operaciones, si desea controlar quién puede acceder al formulario y si desea controlar dónde se puede incrustar el formulario.
Repercusión de objeto Determine si su formulario operará contra un único objeto o contra múltiples objetos.
Automatización de pruebas de interfaz de usuario Determine si sus procesos de DevOps requieren que su formulario se someta a pruebas de unidad automatizadas o pruebas de extremo a extremo automatizadas.
Métricas Identifique cómo le gustaría realizar un seguimiento del uso de su formulario, incluyendo vistas de página, cantidad de tiempo empleado en el formulario, índices de realización y índices de éxito.
Empaquetado e implementación Determine cómo desea distribuir o implementar su formulario después de su creación.
**Nota:** En tablas de comparación de decisiones posteriores, hay un puñado de valores asociados con cualquier par de funciones de herramientas: - **Disponible:** La herramienta/función funciona con consideraciones básicas. - **No disponible:** No hay planes para agregar asistencia en los próximos doce meses. - **No es ideal:** Esta herramienta/función puede funcionar, pero no es la herramienta óptima. - **No aplicable:** La herramienta no se aplica al caso de uso concreto. ## Casos de uso Utilice estos escenarios para comparar opciones de herramientas basadas en ámbito, UX y necesidades operativas. ### Ámbito y navegación de formularios Si puede obtener todas sus entradas de usuario desde un formulario de pantalla única, comience con Formularios dinámicos. Recuerde que Formularios dinámicos en páginas de registro pueden utilizar la función Ruta para dar cobertura a procesos de negocio por etapas. #### Preguntas para formular - ¿Necesita una sola pantalla o el usuario tendrá que navegar entre múltiples pantallas para completar una tarea? - ¿Desea que sus usuarios vean una representación visual de lo avanzado que están en el proceso al rellenar su formulario? ¿Se requerirá que sus usuarios rellenen la información de cada pantalla en un orden específico, o deben poder moverse de un lado a otro entre pantallas según sea necesario? Si necesita más funciones de las que ofrece Formularios dinámicos, la elección entre Flujo, OmniStudio y LWC depende de algunas preguntas adicionales: - ¿Está bien mostrar una barra de navegación en la parte inferior de su formulario? Si la experiencia de navegación de Flujo de pantalla y OmniScript proporciona una UX no deseada, inclínese hacia LWC. - ¿Qué debe ocurrir detrás del formulario? Si necesita que un administrador pueda configurar el comportamiento, utilice un Flujo. Para relaciones complejas de múltiples objetos, utilice _OmniScript_ o _LWC_.
Pantalla única Formulario de múltiples pantallas Indicadores de progreso Saltar la navegación entre pasos/pantallas
Formularios dinámicos Disponible No disponible Disponible No disponible
Flujo de pantalla Disponible Disponible Disponible No disponible
Omnistudio Disponible Disponible Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible
LWC Disponible No es ideal No es ideal No es ideal
Si selecciona Flujo u OmniStudio, es posible que también necesite crear un LWC para alcanzar la UX correcta. Si ya está creando un LWC para diseñar su formulario correctamente, considere si es necesario [integrar ese componente en un flujo](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow). **Navegación de estilo asistente** Por otro lado, si su solución tiene el aspecto de un asistente (donde el usuario navega entre múltiples pantallas), considere Flow u OmniStudio. Flujos y OmniStudio incluyen un modelo de navegación integrado, de modo que no tiene que crear y mantener LWC que están encadenados juntos. La navegación es lineal, con acciones de avance, acciones de retroceso y un mecanismo para guardar el formulario para más adelante. También puede crear un formulario con navegación no lineal si se ajusta a sus fines. OmniStudio ofrece una ventaja de navegación clave proporcionando indicadores de progreso desde la navegación estándar que afloran pasos en el formulario. La vista de paso muestra automáticamente dónde está un usuario en un formulario de múltiples pasos. A diferencia de Flujo, permite a los usuarios saltar entre pantallas haciendo clic en varios pasos en todo el formulario. Independientemente de que esté creando formularios de pantalla única o múltiples pantallas, es importante asegurarse de que sus formularios se simplifican de modo que sean fáciles de navegar para sus usuarios. ### Factor de forma Si está incrustando un formulario en una página de registro Lightning estándar, cualquiera de las herramientas que estamos comparando funcionará. Sin embargo, Formularios dinámicos solo están disponibles en estos momentos en el escritorio. Si desea proporcionar una experiencia que permita a los usuarios acceder a formularios desde otras ubicaciones, es posible que tenga que considerar opciones alternativas. #### Preguntas para formular - ¿Necesitarán los usuarios acceder al formulario a través de escritorio, móvil o ambos? - ¿Deberían los usuarios poder acceder al formulario desde cualquier parte de su aplicación a través de una barra de utilidades? - ¿Desea activar acciones rápidas para que los usuarios puedan rellenar su formulario sin tener que abandonar la página en la que se encuentran actualmente? - ¿Necesita su formulario estar disponible en un sitio web externo?
Página de registro Lightning Página de inicio o página de aplicación Lightning Sitios de Aura Experience Cloud Sitios de LWR Experience Cloud Snap integrados Barra de utilidades Acción específica de objeto Acción global Aplicación móvil Salesforce* Field Service Mobile SDK móvil Sitios y aplicaciones externos LWC personalizado
Formularios dinámicos Disponible No disponible No disponible No disponible No disponible No disponible No disponible No disponible Disponible No disponible No disponible No disponible No disponible
Flujo de pantalla Disponible Disponible Disponible Disponible Disponible Disponible Disponible No disponible Disponible Disponible** No disponible No disponible Disponible
Omnistudio Disponible Disponible Disponible No disponible No disponible Disponible No disponible No disponible Disponible No disponible No disponible Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible Disponible Disponible No disponible Disponible No disponible No disponible No es ideal Disponible
LWC Disponible Disponible Disponible Disponible Disponible Disponible No disponible No disponible Disponible No disponible No disponible Disponible Disponible
*Flujos y LWC son compatibles con la aplicación móvil Salesforce, pero no admite todas las formas de incrustar flujos y LWC (por ejemplo, las acciones específicas de objetos son compatibles con dispositivos móviles, pero los elementos de la barra de utilidades no).

**La aplicación móvil Salesforce Field Service incluye Captura de datos: una solución de formularios sin conexión en primer lugar construida sobre el motor de flujos con un tiempo de ejecución sin conexión exclusivo, compatible con las funciones de flujo más recientes. La aplicación también incluye los flujos móviles de Field Service heredados, que se ejecutan en un motor sin conexión personalizado más antiguo, y no admite muchas de las funciones de flujo más recientes.
Puesto que requiere contexto de registro, la función Formularios dinámicos solo se admite en páginas de registro Lightning. Sin embargo, Formularios dinámicos no es compatible en páginas de Experience Cloud. Puede crear flujos que requieren un contexto de registro o flujos que funcionan de forma global. En otras palabras, puede integrar flujos en una variedad de ubicaciones. Para flujos contextuales de registros, las ubicaciones pueden incluir: Páginas de registro Lightning, páginas de registro de Experience Cloud, acciones específicas de un objeto o implementaciones de Acciones y recomendaciones. Para flujos globales, las ubicaciones pueden incluir: la barra de utilidades, otras páginas Lightning o Experience Builder, Snap o aplicaciones externas. Actualmente, los flujos no son compatibles como acciones globales, pero puede incluir _los flujos_ en un componente _Aura_ como solución. OmniStudio le permite crear FlexCards y OmniScripts componibles que puede colocar en _casi_ cualquier lugar donde pueda colocar un Flujo, pero aunque son componibles, no son empaquetables. LWC ofrece un alto grado de reutilización para la creación de componentes que se pueden asociar con destinos a través de metadatos en Salesforce, Comunidades y proyectos de código abierto. Los componentes LWC también se pueden integrar en su propio sitio web utilizando [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html). Lightning Out on External Sites Los componentes LWC también pueden iniciar flujos con el componente [Lightning Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation). OmniStudio destaca en la exposición de contenido a sitios externos a través de la función OmniOut. Con OmniStudio y OmniOut, puede compilar sus formularios de OmniScript y componentes FlexCard en componentes estándar, y luego ejecutarlos fuera de la plataforma en sitios o aplicaciones externos. Actualmente, ninguna de las tecnologías de formularios que se tratan en esta guía es compatible oficialmente en plantillas de Mobile SDK. Si Mobile SDK es esencial para su caso de uso, recomendamos crear su formulario de forma nativa en su aplicación móvil o crear una página Visualforce, teniendo en cuenta al mismo tiempo el factor de forma. ### Lógica Formularios dinámicos son perfectos si necesita utilizar los valores de su formulario para crear o actualizar un registro. Necesitará aprovechar Flow, OmniStudio o LWC para funciones fuera de ese ámbito, incluyendo la creación de capas de decisiones o iteraciones o la generación de publicaciones o mensajes de email de Slack utilizando las entradas del formulario. #### Preguntas para formular - ¿Qué acciones o lógica se deben realizar en segundo plano? - ¿Necesita utilizar valores de un registro relacionado? - ¿Necesitará su formulario completar sus operaciones en una sola transacción o entre múltiples transacciones? - ¿Necesita integrar con sistemas externos? - ¿Cuáles son sus requisitos de reutilización y modularidad?
Registro y acciones Gestión de datos jerárquica Operar en una sola transacción Operar entre múltiples transacciones Integración Diseño modular y reutilización Empaquetado
Formularios dinámicos No disponible No disponible No disponible No disponible No disponible No disponible Disponible
Flujo de pantalla Disponible No disponible Disponible Disponible Disponible Disponible Disponible
Omnistudio Disponible Disponible Disponible Disponible Disponible Disponible No disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible Disponible Disponible
LWC Disponible Disponible Disponible Disponible Disponible Disponible Disponible
Flow ofrece acciones estándar para publicar en Slack, enviar emails e interactuar con documentos Quip, y no tiene que redactar código para ninguna de estas operaciones. LWC ofrece interacciones enriquecidas con registros únicos y objetos relacionados a través de adaptadores de red que interactúan con la [API de interfaz](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm) de usuario. LWC también puede interactuar con múltiples registros utilizando el cable para [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html). LWC Interaction via Wire Adapters OmniStudio utiliza procedimientos de integración y Asignador de datos para obtener y transformar datos (tanto externos como internos en Salesforce). Debido a las numerosas funciones libres de código, destaca en el aplanamiento y la ampliación de conjuntos de datos con varios niveles de relaciones. Flow, OmniStudio y LWC se integran con Apex, de modo que puede cerrar fácilmente cualquier brecha en la solución que elija (por ejemplo, si necesita filtrar registros desde un LWC, puede utilizar el adaptador de red para Apex para crear consultas SOQL complejas. Si se deja influir por historias basadas en clics, considere utilizar Flow u OmniStudio como una alternativa viable a un controlador Apex para sus necesidades del lado del servidor. También debe considerar si desea confirmar acciones de inmediato o aplazarlas a una parte concreta de su formulario. Esto es especialmente relevante si está utilizando un formulario de varias páginas. Flujo facilita combinar entradas desde múltiples formularios (pantallas de flujo) y utilizarlas más adelante en el asistente (flujo) para realizar ciertas operaciones, que es exactamente como recomendamos diseñar Flujos. Realice acciones al final (en caso de que los usuarios reboten entre pantallas para cambiar sus respuestas). #### Operaciones de control Las transacciones y los [límites reguladores](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) forman parte integral de Agentforce 360 Platform. Si su caso de uso es bastante sencillo, es posible que no sea tan importante controlar la transacción donde se produce una operación concreta. Sin embargo, existen algunos casos de uso en los que es posible que desee combinar múltiples operaciones en una sola [transacción en](/docs/architect/es-mx/fundamentals/guide/architecture-basics#transacciones) vez de realizarlas en múltiples transacciones. Estos son algunos ejemplos: - **Reversión:** Supongamos que su formulario crea múltiples registros en segundo plano. Si la creación de un tercer registro falla, ¿se deben revertir los dos primeros registros? Si cada una de sus acciones son independientes entre sí, puede ejecutarlas como transacciones separadas. Sin embargo, si dependen unos de otros (y desea que el fallo de uno también revierta los otros), debe implementarlos como una sola transacción. Si su formulario está en Flujo, puede utilizar el elemento Reversión en la ruta Fallo para revertir su transacción y garantizar la integridad de los datos. - **Repercusión descendente en límites reguladores:** Cuando su formulario crea o actualiza un registro, es importante considerar cuáles son las implicaciones descendentes de esa operación: - ¿Qué procesos, reglas de flujo de trabajo, desencadenadores de flujo, desencadenadores Apex u otros elementos de la orden de guardado pueden activarse en función de los cambios de registro propuestos? - ¿Cómo afectan esos cambios colectivos a los límites reguladores que se están consumiendo en esa transacción? - Si un cambio de registro concreto puede dar como resultado muchos cambios descendentes que afectan a sus límites, es mejor considerar aislar ese cambio de registro en su propia transacción. - **Procesamiento por lotes:** Es posible que necesite realizar múltiples actualizaciones por lotes juntas (incluso en un contexto de interfaz de usuario). Supongamos que su formulario de múltiples pantallas itera sobre un gran grupo de registros. En vez de confirmar una actualización de registro después de cada pantalla (espere a que haya recopilado las actualizaciones para todos los registros) y luego envíe una solicitud para actualizar todos los registros. Cuando utiliza Formularios dinámicos para crear o modificar un registro, solo está realizando una operación, y esa operación es siempre el inicio de una transacción nueva neta. Cuando está creando un flujo de pantalla, tiene un control significativo sobre lo que se produce en una transacción concreta. Las pantallas y las acciones locales actúan como límites entre transacciones. Este es un resumen de alto nivel de cómo se gestionan las transacciones en la arquitectura de flujo de pantalla. 1. El usuario final interactúa con una pantalla y luego hace clic en **Siguiente**. 2. El cliente publica una solicitud de entrada en la API. 3. La API recibe la solicitud y abre una transacción y una conexión de base de datos. A continuación, la API llama al motor de flujos para invocar la solicitud. 4. El motor de flujos toma el relevo y sigue la ruta apropiada en la definición del flujo, hasta que alcanza una pantalla o un nodo de acción local. A continuación, el motor devuelve información acerca de ese nodo a la API. 5. La API crea un objeto de respuesta que contiene los detalles de la siguiente pantalla para representar y devuelve ese objeto al cliente. En este punto, se confirman los cambios de la base de datos (según la [ejecución del pedido](/docs/architect/es-mx/fundamentals/guide/architecture-basics#manipulación-de-base-de-datos) de guardado) y se cierran la conexión y la transacción de la base de datos. 6. El cliente utiliza la respuesta de API para representar la siguiente pantalla con la que interactúa el usuario. 7. Comience desde el paso 1 y repita el proceso. En otras palabras, las pantallas _rompen_ transacciones. Cuando esto ocurre, cualquier acción pendiente o DML se confirma, la transacción anterior se cierra y comienza una nueva transacción. multi-screen flow Recuerde que los elementos de diseño específicos (qué operaciones agrupa en una transacción concreta) dependen de usted. Estos son algunos ejemplos: screen flow with separate transactions - Cuando comience, verá un flujo que recopila entradas entre múltiples pantallas y luego realiza varias acciones en una transacción. - El siguiente flujo realiza cada operación en una transacción separada. - Los flujos también pueden utilizar Revertir registros para permitirle revertir una transacción completa si una sola operación falla en una serie de operaciones de la base de datos. Screen Flow with multiple create records Supongamos que tiene un flujo que crea registros, actualiza registros y luego crea registros adicionales (ilustrados en el siguiente flujo). En este escenario, si los dos primeros elementos tienen éxito y el último falla, las dos primeras operaciones DML aún crean y actualizan los registros apropiados, pero el tercero no. Screen Flow with Rollback Utilizando el elemento Revertir registros, puede asegurarse de que se revierte toda la transacción si las tres operaciones deben producirse de forma colectiva (como se ve en el flujo final). **Nota:** Para obtener más detalles, consulte [Flujos en transacciones](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) y [Flujo masivo en transacciones](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm). Su capacidad para controlar la transacción desde un LWC se basa en los servicios subyacentes que el LWC está utilizando para realizar sus operaciones. Si está utilizando el componente base de formulario Lightning, la operación subyacente (creación o actualización del registro) se produce en una transacción independiente cuando se envía el formulario. En general, se aplican estas reglas: - Cada llamada de API de la interfaz de usuario está aislada en su propia transacción. - Si necesita realizar múltiples operaciones en una sola transacción, envíe las entradas a una tecnología del lado del servidor (por ejemplo, un controlador Apex o un flujo). Tenga en cuenta que las reglas de transacciones regulares para esa tecnología aún se aplican. #### Integraciones externas Flow, OmniStudio y LWC admiten eventos de plataforma (para [arquitectura dirigida por](/docs/architect/es-mx/decision-guides/guide/event-driven) eventos) e integraciones de API. Además del código Apex personalizado, Flow y OmniStudio tienen mecanismos de asistencia declarativa que también se pueden integrar con las API. Si necesita conectarse a una API de MuleSoft o bot de RPA, utilice Servicios de MuleSoft, ya que esto genera un Servicio externo. External integrations via MuleSoft Si la API tiene un esquema de OpenAPI, cree un Servicio externo. External Integrations via OpenAPI Para el resto de instancias, utilice la función **Llamada HTTP** (con tecnología de Servicios externos) en Flujo o la **Acción HTTP** en OmniStudio. External integrations via HTTP OmniStudio cuenta con un conjunto enriquecido de funciones de integración que pueden llamar a sistemas externos utilizando procedimientos de integración para transformar datos a través del Asignador de datos. Independientemente de si utiliza código Apex personalizado o un servicio externo para la implementación, una **llamada** sigue siendo una llamada. Esto es lo que necesita saber. - Una llamada puede tardar una cantidad significativa de tiempo en procesarse. - Cuando una llamada se ejecuta de forma síncrona, se realiza mientras una transacción de base de datos está abierta. - Salesforce no le permite mantener una transacción de base de datos abierta si tiene operaciones de base de datos pendientes. Recuerde que la principal limitación es el peligro de dejar datos en un estado incoherente, que se produce cuando realiza una operación de **creación**, **actualización** o **eliminación** y luego ejecuta una **llamada** en la misma transacción. Este patrón no está permitido debido a la tercera consideración mencionada anteriormente, que existe debido a las dos primeras consideraciones. En Flujo, puede omitir esta limitación rompiendo la transacción. Recuerde que las pantallas y las acciones locales vuelven a introducir el contexto del navegador. Aunque puede utilizar pantallas y acciones locales cuando está trabajando con llamadas externas, recomendamos activar **Control de transacciones** en la configuración avanzada invocable. Control de transacciones le permite finalizar automáticamente la transacción antes de que se realice una llamada. Para activar Control de transacciones, seleccione “**Iniciar siempre una nueva transacción**” en la sección **Avanzado** de la acción invocada. External Integrations via Callouts LWC ayuda a simplificar la repercusión de las llamadas en la transacción. En otras palabras, realice sus operaciones de datos utilizando Lightning Data Service (LDS) y luego utilice un controlador Apex para realizar la llamada externa. Puesto que la llamada LDS está aislada en su propia transacción (separada de la llamada Apex), esto le protege de la incoherencia de datos resultante. #### Reutilización y modularidad Formularios dinámicos no admite la reutilización. Cada uno está vinculado a una página de registro Lightning específica para un objeto específico; sin embargo, puede asignar esa página de registro Lightning a múltiples aplicaciones, perfiles, etc. Del mismo modo que puede redactar bibliotecas, utilidades y componentes que se pueden utilizar entre múltiples componentes, también puede aplicar patrones de diseño similares cuando está creando flujos aprovechando la potencia de **los subflujos**. Para ello, guarde sus flujos en depósitos modulares más pequeños y luego llámelos desde otros flujos utilizando el elemento **Subflujo**. Si su diseño lo requiere, puede crear un flujo que sea útil por sí solo y como un flujo secundario. OmniStudio está construido de forma inherente para la modularidad. Asignadores de datos, OmniScripts, FlexCards y Procedimientos de integración se crean de forma independiente, pero también pueden funcionar indistintamente. Las FlexCards también se pueden crear como componentes LWC que se pueden integrar en otros LWC, OmniScripts, páginas de registro y sitios de Experience Cloud. Los flujos de pantalla, los OmniScripts y los LWC pueden crearse para su reutilización e incrustarse en una variedad de ubicaciones, incluyendo sitios externos y aplicaciones Lightning Out. Cuando diseña sus soluciones para que sean componibles, también obtiene beneficios de adaptabilidad y estabilidad. ### Validación Todas las tecnologías que se utilizan para crear o actualizar registros deben adherirse a la validación a nivel del sistema, ya sean reglas de validación clásicas o validaciones personalizadas integradas en un desencadenador Apex. Independientemente de la tecnología que utilice para realizar cambios de registro, cada cambio debe pasar por la orden de guardado. Esto significa que además de las reglas de validación, los cambios de registro también se procesan por un número de flujos antes o después de guardar, desencadenadores antes o después, reglas de distribución, reglas de asignación, etc. **Nota:** Si aún no lo hizo, revise y marque como favorito el [orden de ejecución](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) de Apex. #### Preguntas para formular - ¿Tiene su formulario algún requisito adicional más allá de la validación a nivel del sistema? - ¿Necesita establecer campos obligatorios o de solo lectura de forma dinámica en el formulario?
Respetar validación a nivel del sistema Validación a nivel de campo personalizada específica de este formulario Validación a nivel de campo personalizada
Formularios dinámicos Disponible No disponible No disponible
Flujo de pantalla Disponible No disponible No disponible
Omnistudio Disponible Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible
LWC Disponible Disponible Disponible
Normalmente, las entradas en una pantalla de flujo o paso de OmniScript no están vinculadas, de modo que el formulario en sí no se adhiere de forma nativa a la validación a nivel del sistema asociada con un objeto concreto. Sin embargo, los valores que utiliza para crear o actualizar registros se procesan en el orden de guardado, lo que significa que pasan por la validación a nivel del sistema del objeto. **Nota:** No todos los componentes Flujo de pantalla admiten la validación de entrada. Al igual que los formatos de página, Formularios dinámicos le permite establecer la **obligación** y el estado de **solo lectura** a nivel de página. Recuerde que no puede sustituir la configuración a nivel del sistema. Flujo proporciona flexibilidad para personalizar la validación de entrada de formulario. Se realizan múltiples comprobaciones a nivel del cliente (por ejemplo, marcando campos obligatorios que faltan y comprobaciones de tipo de datos, así como fórmulas compatibles en reglas de validación de entrada). Como un nivel de seguridad agregado, la validación de entrada también se evalúa en el servidor. Cuando un usuario hace clic en **Siguiente**, Flujo envía las entradas al servidor para su validación de nuevo. Si se devuelven entradas no válidas, la navegación se bloquea y se muestra el error apropiado. El servidor valida las entradas comprobando: - La configuración de **requisitos** de la entrada o si el valor ingresado es compatible con el tipo de datos subyacente. - La validación personalizada de la entrada. Debe proporcionar una expresión de fórmula _booleana_ y un mensaje de error para mostrar cuando no se cumpla la expresión de fórmula. - La validación personalizada del componente subyacente. Si está creando un LWC personalizado para un flujo, debe agregar su propio código de validación al método validate(). También puede proporcionar alertas de usuario accesibles a través del componente **Mensaje** en Flujos de pantalla, pero esto no evita que un usuario navegue a otras páginas o progrese al siguiente paso en un Flujo guiado. El estado _Error_ en el componente **Mensaje** se utiliza mejor en pantallas de error dedicadas que se desencadenan a través de una ruta de fallo cuando se desactiva la navegación. OmniStudio cuenta con una sólida gestión de errores y validación a través de la acción [Establecer error](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) en combinación con [Vistas condicionales](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) y el componente [Mensajería](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5). Para LWC, la mayoría de los componentes base realizan sus propias validaciones del lado del cliente (por ejemplo, Lightning respeta la obligatoriedad a nivel del sistema, pero no la obligatoriedad a nivel de página). Para sus componentes personalizados, puede Build Your Own mecanismos de validación. Recuerde que los campos que requieren que los usuarios ingresen datos deben aparecer al principio de sus formularios. Valide entradas de usuario en el lado del cliente antes de enviar formularios (cuando sea posible). ### Diseño de interacciones Los formularios estáticos están desfasados. Hoy en día, el enfoque cambió a la actualización dinámica de formularios con las propiedades y los valores correctos para un usuario _específico_, en un momento _específico_, en un lugar _específico_. Echemos un vistazo con más detalle a lo que es factible a través de herramientas de creación de formularios de Salesforce. #### Preguntas para formular - ¿Qué tipos de interacciones o condiciones deben desencadenar respuestas dinámicas en su formulario? - ¿Necesita ejecutar operaciones fuera de la pantalla (en segundo plano) mientras se rellena su formulario? - ¿Necesita establecer campos como **visibles**, **obligatorios**, de **solo lectura** o **desactivados**, o necesita cambiar el formato basándose en entradas de formulario?
Ejecutar operaciones de datos fuera de pantalla Valores condicionales y cálculos Visibilidad condicional Requisito condicional Formato condicional Estado de solo lectura condicional Estado desactivado condicional
Formularios dinámicos No disponible No disponible Disponible No disponible Disponible No disponible No disponible
Flujo de pantalla Disponible Disponible* Disponible Disponible No disponible Disponible Disponible
Omnistudio Disponible Disponible Disponible Disponible Disponible Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible Disponible Disponible
LWC Disponible Disponible Disponible Disponible Disponible Disponible Disponible
*Limitado a componentes que utilizan un selector de recursos y no una casilla de verificación estática
**Pantallas reactivas** activa la interactividad Flujo de pantalla. La reactividad permite que los componentes individuales en una pantalla de flujo se comuniquen entre sí, lo que hace que los flujos de pantalla sean más potentes. **Ejecutar operaciones de datos fuera de pantalla** Los flujos de pantalla proporcionan un enfoque declarativo para obtener datos en la misma pantalla a través de **Acciones de pantalla**. Las acciones de pantalla le permiten desencadenar flujos iniciados automáticamente en cualquier cambio en la pantalla, o cuando un usuario hace clic en un componente **Botón de acción**. Puede asignar resultados de flujo iniciados automáticamente a la misma pantalla, lo que elimina la necesidad de que los usuarios naveguen a otra pantalla. LWC proporciona una gama completa de adaptadores de red que proporcionan acceso a datos de Salesforce para rellenar dinámicamente datos en componentes de formulario, lo que permite a los desarrolladores **actualizar**, **eliminar** y **crear** registros a través de controladores Apex. Lightning Web Components Off-Screen Data Operations **Visibilidad** La visibilidad se puede controlar de forma dinámica en todas las herramientas de creación de formularios. Formularios dinámicos, Flow Builder y OmniStudio solucionan esto utilizando funciones de visibilidad de componentes. Puede **mostrar** u **ocultar** de forma declarativa campos basándose en otros valores en el formulario, o si el usuario está completando el formulario en un dispositivo móvil. - Formularios dinámicos controla la visibilidad basándose en valores de campo de registro, campos de búsqueda y factor de forma. - Con Flujo, puede basar una regla de visibilidad en otras entradas de pantalla, así como otros recursos que se rellenan anteriormente en el flujo (por ejemplo, fórmulas o valores de otros registros). - **Reglas basadas en dispositivos:** Puede no ser obvio desde el principio, pero puede utilizar una fórmula para **mostrar** u **ocultar** un campo concreto cuando el usuario está en un dispositivo móvil. Escriba una fórmula de flujo que compruebe el valor de la variable global **$User.UIThemeDisplayed**. Si el valor es **Theme4t**, el usuario está completando el formulario utilizando la aplicación móvil Salesforce. - **Evaluar otros recursos:** Las referencias de fórmula y variable manuales solo se evalúan en el servidor. Esto significa que el valor que tiene ese recurso cuando se representa la pantalla por primera vez es el valor que tendrá hasta que navegue a otra pantalla. Durante la navegación, el tiempo de ejecución del flujo envía una solicitud al motor de flujos (el servidor) y devuelve la variable manual y los valores de fórmula más recientes. Si espera que su regla de visibilidad se actualice a medida que el usuario pasa por una única pantalla (por ejemplo, desenfoque), debe asegurarse de que solo hace referencia a valores de los otros componentes en la pantalla. - Con OmniStudio, puede **mostrar** u **ocultar** componentes de forma condicional configurando una propiedad **Vista condicional**. Sin embargo, no puede agregar más de una propiedad Vista condicional para una entrada. **Estados de entrada condicionales** Si necesita controlar dinámicamente cualquier otra propiedad (por ejemplo, si un campo es **obligatorio**, **desactivado** o de **solo lectura**), existen algunas opciones. LWC proporciona un control reactivo completo sobre su estado de entrada. Con componentes Flujo de pantalla reactivo, puede controlar dinámicamente atributos de componente (por ejemplo, **solo lectura**, **desactivado** y **obligatorio**) para componentes estándar que lo admiten, mientras que OmniStudio admite el espectro completo de atributos específicos de componente. Si sus requisitos dictan que necesita Flujo y el componente no admite un estado de atributo específico, puede crear un LWC incrustable para alcanzar un estado de entrada dinámico. Si necesita controlar dinámicamente cualquier otra propiedad (por ejemplo, si un campo es **obligatorio** o de **solo lectura**), utilice LWC a corto plazo ya que tiene el control completo. Esto es especialmente cierto si tiene requisitos personalizados sobre cómo gestionar el desenfoque o el onclick. **LWC reactivos en flujos de pantalla** Si está creando LWC que pueden reaccionar y cambiar otros componentes en un flujo de pantalla, consulte la guía [Mejores prácticas LWC para flujos](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) de pantalla para asegurarse de que sus componentes se integran con el motor de tiempo de ejecución de flujos y funcionan según lo previsto.
Gestión de eventos estándar(desenfoque, enfoque) Gestión de eventos personalizados
Formularios dinámicos No disponible No disponible
Flujo de pantalla No disponible No disponible
Omnistudio No disponible Disponible*
Flujo de pantalla + LWC Disponible Disponible
LWC Disponible Disponible
*El Tiempo de ejecución estándar de OmniStudio no admite Pub/Sub, pero admite Windows postMessage
Para eventos personalizados, si algunas de sus entradas (o el formulario completo) necesitan comunicarse con otro elemento en la página, LWC es su única opción. - Para comunicarse dentro del mismo árbol DOM, utilice la [interfaz CustomEvent](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events). - Para comunicarse en el DOM, utilice el [Servicio Lightning Messaging](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel). - Si Servicio de mensajería Lightning [no es compatible](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) con su contenedor de destino, utilice el módulo pub/sub. #### Recursos adicionales para el diseño de interacciones - Para obtener información más detallada, consulte [Comunicarse con eventos](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) y [comunicarse a través del DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) en la _Guía del desarrollador_ de componentes web Lightning. - Para OmniStudio, consulte [Comunicarse con OmniScript desde un componente web Lightning.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5) ### Estilo Para proporcionar la mejor experiencia de usuario, es importante asegurarse de que su estilo de formulario es coherente con el resto de la aplicación o el sitio donde se está incrustando. Esto puede significar el uso de plantillas estándar proporcionadas por Salesforce, o la creación de un CSS personalizado que utiliza cada píxel en el diseño para proporcionar un aspecto más nítido. #### Sustituciones de estilo de flujo de pantalla Los administradores pueden configurar un conjunto limitado de sustituciones de estilo de pantalla y componente (por ejemplo, colores, bordes y apariencias de botones), para el contenedor de pantalla o para componentes individuales. Estas sustituciones se aplican después de temas y marca, lo que permite a los constructores realizar ajustes visuales dirigidos sin afectar al resto de la aplicación. Las sustituciones de estilo están pensadas para excepciones visuales localizadas (por ejemplo, resaltando una pantalla de confirmación o enfatizando una llamada a la acción específica (CTA); no son un sistema de estilo completo. No proporcionan control a nivel CSS y no están diseñados para reutilizarse entre pantallas o flujos. Desde una perspectiva arquitectónica, el estilo debe seguir este orden precedente: 1. **Temas y marca:** Temas Lightning, Conjuntos de marca de Experience Builder o Temas de sitio LWR 2. **Sustituciones de estilo de flujo:** Pantalla dirigida o ajustes de componente 3. **Componentes personalizados (LWC):** cuando se requiere un control perfecto de píxeles o patrones de diseño reutilizables El uso de temas y sistemas de diseño ayuda a garantizar que el estilo permanece coherente, ampliable y fácil de mantener a lo largo del tiempo. #### Preguntas para formular - ¿Qué tan sofisticado es su estilo y CSS deseados? - ¿Necesita un estilo personalizado y perfecto para los píxeles o temas estándar?
Estilo directo Temas de organización y Experience Builder Estilo perfecto para píxeles
Formularios dinámicos No disponible Disponible No disponible
Flujo de pantalla No disponible Disponible Disponible**
Omnistudio Disponible* No disponible Disponible
Flujo de pantalla + LWC No disponible Disponible Disponible
LWC No disponible Disponible Disponible
*Solo FlexCards

**Se pueden configurar ciertos atributos de estilo para componentes de pantalla, pero no sustituciones CSS.
FlexCards es el único producto de esta guía que le permite controlar de forma declarativa el estilo y el formato de la interfaz de usuario que está creando en la herramienta (por ejemplo, márgenes y relleno, tipografía, colores, etc.). Los flujos y formularios dinámicos respetan las funciones de tema declarativo. Si necesita control adicional (más allá de lo que admiten [Salesforce Themes](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [Experience Builder Branding Sets](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) o [LWR Experience Cloud Sites](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm)), considere una solución programática. Los equipos que se sienten cómodos trabajando con CSS tienen varias opciones: - Los flujos y los LWC heredan [tokens de diseño estándar](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm). - Los OmniScripts y FlexCards incluyen compatibilidad con el sistema de diseño personalizable a través de [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5). - Con LWC, puede redactar sus propios componentes y controlar completamente sus HTML y CSS. Cuando sea posible, recomendamos utilizar temas y sistemas de diseño para garantizar un aspecto coherente en todo su contenido. **Nota:** Puede integrar componentes Lightning en Flujos. Si necesita un control perfecto de píxeles sobre el aspecto de su formulario, pero también desea utilizar los otros beneficios de Flujos (por ejemplo, el modelo de navegación), puede tener lo mejor de ambos mundos. El mismo principio se aplica a OmniScripts y FlexCards. ### Formato La selección de un buen formato es crucial para diseñar formularios simplificados que permiten el ingreso de datos rápido y eficiente y aumentan la integridad de los datos. #### Preguntas para formular - ¿Cómo puede estructurar formatos de formulario para optimizar experiencias de usuario? - ¿Cómo puede presentar datos existentes a usuarios de una forma que les facilite ingresar nuevos datos en sus formularios?
2 columnas 4 columnas Más allá de 4 columnas Bloques de datos repetitivos Ficha Contenedores Contenedores de acordeón
Formularios dinámicos Disponible No disponible No disponible No disponible Disponible Disponible
Flujo de pantalla Disponible Disponible No disponible Disponible No disponible Disponible
Omnistudio Disponible Disponible Disponible Disponible Disponible* Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible Disponible
LWC Disponible Disponible Disponible Disponible Disponible Disponible
*Las fichas se pueden utilizar si se incrustan datos en una FlexCard en un OmniScript
Formularios dinámicos admite formatos de dos columnas que se pueden dividir en secciones individuales en campos. Estas secciones se pueden colocar en componentes (por ejemplo, fichas y acordeones) para crear formatos organizados y fáciles de utilizar. Los flujos también se pueden representar utilizando el componente **Sección**. Puede agregar hasta cuatro columnas y un número ilimitado de secciones en la pantalla de flujo. El componente secciones también tiene capacidad de respuesta a la anchura de pantalla, de modo que también funciona en pantallas más pequeñas. Le proporciona la capacidad de aplicar visibilidad condicional a toda la sección, lo que facilita la aplicación masiva de visibilidad a múltiples campos dentro de la sección. Las **secciones de flujo** también admiten encabezados de columna y ofrecen una experiencia similar a un acordeón donde los usuarios pueden contraer la sección completa haciendo clic en la etiqueta. Los OmniScripts incluyen una variedad de opciones de formato para mostrar campos y datos. Puede crear secciones de datos con hasta 12 columnas, incluyendo acordeones contraíbles condicionalmente. Con LWC, puede utilizar Lightning y el campo Lightning para controlar el formato. Las únicas restricciones de formato proceden de HTML y CSS. El componente **Lightning-record-form** respeta la configuración de la sección en el formato de página asociado (por ejemplo, si una sección tiene dos columnas en el formato de página, también tiene dos columnas en el componente). ### Traducción Si su formulario necesita ser accesible para usuarios en diferentes regiones o que hablan diferentes idiomas, debe asegurarse de que la herramienta que está utilizando para crearlo cumple sus requisitos de localización. **Nota:** Para formularios específicamente, los requisitos de localización normalmente implican traducir elementos de texto a otros idiomas. #### Preguntas para formular - ¿Se utilizará su formulario en más de un país o región? - ¿Necesita el texto de su formulario estar traducido a otros idiomas?
Etiquetas ingresadas en el generador Etiquetas en el código
Formularios dinámicos Disponible* No disponible
Flujo de pantalla Disponible Disponible
Omnistudio Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible
LWC No aplicable Disponible
*Solo encabezados de sección de campo
Si localiza campos personalizados, Formularios dinámicos respeta las etiquetas traducidas. Formularios dinámicos también respeta cualquier [etiqueta personalizada asignada a etiquetas y atributos](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) de componentes en Lightning App Builder. Flow admite la traducción de etiquetas de cara al usuario para todos los componentes de pantalla estándar y personalizados a través de Sistema de traducción. Puede localizar etiquetas, texto de ayuda y mensajes de error en estos componentes de pantalla: - Texto - Área de texto largo - Número - Divisa - Casilla de verificación - Botones de opción - Lista de selección - Lista de selección múltiple - Contraseña de grupo de casillas de verificación - Fecha - Fecha/hora No hay compatibilidad de traducción integrada para acciones listas para su uso (por ejemplo, Enviar email o Publicar en Chatter), pero hay una solución. Si utiliza una [etiqueta personalizada](https://help.salesforce.com/articleView?id=cl_about.htm) para definir las etiquetas traducidas, puede hacer referencia a esa etiqueta personalizada en la acción o el componente cuando la configura en Flow Builder. Para ello, debe crear una fórmula de flujo que haga referencia a la etiqueta personalizada y luego hacer referencia a esa fórmula en los lugares apropiados de su flujo. Los OmniScripts utilizan etiquetas personalizadas para traducciones. Para obtener más información, consulte [este documento](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm) de ayuda para asegurarse de que sus OmniScripts están listos para varios idiomas. Para LWC, ciertos componentes base heredan automáticamente traducciones de los campos del objeto asociado, texto de ayuda y mensajes de validación si están configurados en Sistema de traducción (por ejemplo, Lightning). Si necesita introducir etiquetas traducibles novedosas en su código, las etiquetas personalizadas son el camino a seguir. Declare la etiqueta personalizada que necesita y luego impórtela en su componente desde el módulo con ámbito de `@salesforce/label`. ## Consideraciones no funcionales Utilice esta sección para evaluar la seguridad, la calidad y las restricciones operativas antes de la implementación. ### Seguridad La seguridad es un tema complejo, y cuando se trata de crear formularios, hay una serie de consideraciones que pueden no ser obvias. A nivel fundacional, debe asegurarse de que el formulario se está ejecutando en el contexto correcto y que los usuarios tienen los permisos que necesitan para trabajar con sus datos subyacentes. Más allá de esto, es posible que también desee tomar medidas adicionales para eliminar códigos o direcciones URL potencialmente maliciosos de campos de texto enriquecido, evitar que ciertos usuarios accedan al formulario o establecer limitaciones en los tipos de ubicaciones donde los administradores pueden integrar el formulario en el futuro. Asegúrese de documentar sus requisitos de seguridad minuciosamente antes de elegir una herramienta. Para obtener orientación adicional sobre este tipo de documentación, consulte la [Plantilla de política](/docs/architect/es-mx/resources/guide/security-policy-template) de seguridad bien arquitectónica de Salesforce. #### Preguntas para formular - ¿Debe el formulario comprobar el acceso del usuario antes de realizar ciertas operaciones? - ¿Debería limpiar las entradas de usuario? - ¿Desea controlar quién puede acceder al formulario? - ¿Desea controlar dónde se puede incrustar el formulario?
Elevar permisos de usuario Controlar quién tiene acceso Restringir ubicaciones permitidas
Formularios dinámicos No disponible Disponible No disponible
Flujo de pantalla Disponible Disponible No disponible
Omnistudio No disponible Disponible No disponible**
Flujo de pantalla + LWC Disponible Disponible No disponible
LWC Disponible* Disponible Disponible
*Requiere Apex

**Aunque los OmniScripts no pueden tener un conjunto especificado de ubicaciones de destino, las FlexCards sí.
#### Elevar permisos de usuario Cuando un programa se ejecuta en **contexto de usuario**, Salesforce aplica una serie de comprobaciones de acceso, que incluyen la verificación de la seguridad a nivel de campo, los permisos CRUD y el acceso a registros basándose en las reglas de colaboración de su organización (por ejemplo, los usuarios solo podrían ejecutar un formulario de actualización de casos si tienen la capacidad de actualizar casos, la seguridad a nivel de campo apropiada y el acceso al registro en cuestión). ¿Qué sucede si desea que los usuarios puedan realizar una operación concreta cuando están utilizando su formulario, pero no a través de ningún otro formulario o interacción? ¡Ahí es donde entra **el Contexto del sistema**! **Contexto del sistema** le permite elevar los permisos de un usuario durante la sesión (por ejemplo, el usuario no necesita actualizar el acceso al objeto Caso para completar correctamente su formulario de actualización de casos). Esto es especialmente útil para comunidades no autenticadas. En vez de otorgar a los usuarios invitados habilidades potencialmente peligrosas, establezca su formulario para ejecutarse en contexto del sistema. Contexto del sistema solo debe utilizarse cuando sea absolutamente necesario. Cuando se ejecuta un formulario en Contexto del sistema, cada operación CRUD omite los componentes de colaboración y seguridad a nivel de objeto y campo. Del mismo modo, Contexto del sistema no influye en quién considera Salesforce como el _actor_ (el nombre que ve en el campo **Última modificación por**). Para cada operación que realice su formulario (por ejemplo, una actualización de caso), el _actor_ es el usuario actual (incluso si el formulario se ejecuta en un contexto diferente). **Nota:** Formularios dinámicos, OmniScripts y LWC siempre se ejecutan en contexto de usuario, y no hay forma de sustituir este comportamiento. Los flujos de pantalla se ejecutan en contexto de usuario de forma predeterminada, pero puede establecerlos para que se ejecuten en contexto del sistema. Puede decidir si el flujo debe otorgar acceso a todos los datos o si debe aplicar acceso a nivel de registro. - Si incrusta un componente Lightning en un flujo que se ejecuta en contexto del sistema, el flujo no sustituirá el contexto del componente. Si necesita omitir las comprobaciones de acceso de usuarios, utilice el flujo para realizar esas operaciones y pasar los datos apropiados dentro o fuera del componente Lightning. Algunos componentes listos para su uso (por ejemplo, Búsqueda) no pueden operar dentro del contexto del sistema. - Si su flujo llama acciones Apex, se implican otros matices. - Si la clase Apex está establecida como _colaboración heredada_, se ejecutará en contexto del sistema con colaboración independientemente de cómo esté establecido el flujo. - Si la clase no tiene ninguna declaración de colaboración explícita, se ejecutará en contexto del sistema sin colaboración independientemente de cómo se establezca el flujo. - Si la clase está establecida como _con colaboración o sin_ colaboración, sustituirá el contexto del flujo. **Consultar registros en contexto del sistema con sitios de Experience Cloud** Si está ejecutando un flujo en contexto del sistema en un sitio de Experience Cloud (especialmente si no está autenticado), almacene solo campos específicos en sus elementos **Obtener registros**. Cuando está trabajando con Flow y pasa los resultados de un elemento **Obtener registros** a un flujo secundario, una acción invocable o un componente Lightning, es posible que las herramientas de desarrollador del navegador inspeccionen todos los campos de ese objeto. A pesar de sus intenciones, esto puede hacer que los campos estén disponibles para usuarios de Experience Cloud. Para asegurarse de que solo se exponen los campos correctos cuando se activa Contexto del sistema, especifique esos campos específicos en sus elementos **Obtener registros**. **Nota:** La lógica de OmniScript se ejecuta en el lado del cliente, lo que permite a los atacantes modificar la ejecución esperada de un OmniScript y ver respuestas a Procedimientos de integración, Asignadores de datos y llamadas de métodos Apex a través de las herramientas de desarrollador del navegador. Cuando está utilizando OmniScript, es importante ejecutar lógica de negocio en el lado del servidor (cuando sea posible) e implementar reglas de validación de entrada para cualquier método Apex expuesto a través de una [anotación @InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5). **Depurar entradas** Para proteger su organización de malos actores, utilice la desinfección de entrada. Supongamos que tiene una entrada en un formulario accesible públicamente que se puede asignar a un campo **Texto enriquecido** en su organización. Es posible que desee considerar activar la automatización que elimina cualquier HTML que pueda ocultar direcciones URL maliciosas. No es ideal implementar la desinfección a nivel de formulario porque puede tener cualquier número de orígenes que escriban en estos campos. Para ayudar a combatir este problema, cree un Flujo de actualización de **campo rápida (Antes de guardar)** o utilice un **Desencadenador Apex** existente para eliminar o modificar cualquier HTML potencial que pueda ingresarse en el formulario. #### Mejores prácticas - Permita que los flujos se ejecuten en su contexto predeterminado (a menos que necesite elevar el acceso del usuario actual para una operación específica). - Evite ejecutar flujos en contexto del sistema para usuarios invitados. Cree conjuntos de permisos con acceso de campo limitado y asígnelos al perfil de usuario invitado de Experience Cloud. - Al consultar registros en Contexto del sistema Ejecutar flujos en sitios de Experience Cloud, almacene únicamente los campos que necesita en el elemento **Obtener registros** o **Acciones invocables**. - Si un flujo realiza una variedad de operaciones, todas las cuales no requieren acceso elevado, utilice Subflujos para aislar las operaciones que deben ejecutarse en Contexto del sistema. - Si está incrustando un formulario en una página web externa, es posible que tenga que asignarse a campos de **Texto enriquecido** para ayudar a evitar posibles ataques de phishing. Para ello, depure las entradas de usuario para eliminar HTML utilizando un **Flujo de actualización** de campos rápida o **Desencadenador Apex**. #### Notas adicionales - OmniScripts, FlexCards y LWC se ejecutan en contexto de usuario de forma predeterminada. - Los LWC se ejecutan en contexto de usuario de forma predeterminada. - Los flujos se ejecutan en contexto de usuario, pero puede sustituirlos utilizando un controlador Apex. - Las operaciones que se realizan en la API de la interfaz de usuario se ejecutan en contexto de usuario. - Las operaciones que se realizan con un controlador Apex dependen de la clase específica. Para realizar estas operaciones en modo sistema, establezca la **clase Apex** en with sharing o without sharing. #### Control de acceso Si necesita controlar quién puede acceder a un formulario, revise el contenedor donde está incrustado el formulario (por ejemplo, puede asignar páginas Lightning para que estén disponibles para aplicaciones, tipos de registro o perfiles concretos). Si ciertas entradas son confidenciales, utilice reglas de visibilidad para controlar aún más lo que se muestra a quién. Esta función se aplica a Formularios dinámicos y Flujos de pantalla. Puede [restringir un Flujo](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) a perfiles o conjuntos de permisos concretos (similar a la clase Apex o páginas Visualforce). Los flujos no están restringidos de forma predeterminada, lo que significa que cualquier usuario con el permiso de usuario **Ejecutar flujos** puede acceder a ellos. Si está utilizando OmniStudio, puede configurar un [comprobador de permisos](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) de clase Apex que requiere que los usuarios tengan acceso explícito a la clase Apex que administra acciones remotas desde las API de OmniScript, Flexcard, Classic Card o REST. **Nota:** Las comprobaciones de permisos de clases Apex solo se aplican a clases Apex. También es recomendable establecer permisos a nivel de perfil para [Procedimientos de integración y Asignadores de datos](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5). #### Mejores prácticas de control de acceso - Si está exponiendo un Flujo a usuarios invitados, solo debe otorgar acceso de perfil de usuario invitado a los Flujos que necesitan absolutamente. Es posible agregar **Ejecutar flujos** a perfiles de usuario invitado; sin embargo, esta práctica puede ser riesgosa. - Tenga cuidado al trabajar con flujos que operan en Contexto del sistema. Debe restringir estos flujos a un conjunto concreto de usuarios ya que tienen menos controles y contrapesos para proteger sus datos. - Asegúrese de que cualquier OmniScript que ejecuta Apex en una comunidad de usuarios invitados tiene **la colaboración** enumerada en la definición de clase Apex. - Para perfiles de usuario invitado, solo asigne las clases Apex que desea permitir a los usuarios invitados llamar. Siguiendo esta práctica, ayuda a evitar exponer involuntariamente lógica de negocio adicional a usuarios invitados. Para LWC, puede comprobar las asignaciones de permisos del usuario actual para confirmar si tiene un permiso estándar o personalizado concreto. Puede importar permisos de Salesforce desde los módulos con ámbito de `@salesforce/userPermission` y `@salesforce/customPermission` directamente en **JavaScript**. También puede utilizar Apex para comprobar permisos. #### Integrar controles Los LWC solo están disponibles en una ubicación determinada después de agregarlos como un [destino](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) válido (por ejemplo, puede hacer que un componente esté disponible en páginas de registro y no como un elemento de barra de utilidades). Una vez activado un Flujo de pantalla, está disponible en todas las ubicaciones que admiten Flujos de pantalla. Flow Builder admite múltiples tipos de flujos que tienen pantallas. El tipo más destacado es **Flujo de pantalla**, pero existen otros tipos especializados restringidos a ubicaciones específicas (por ejemplo, la **aplicación Field Service Mobile** solo admite **Flujos Field Service Mobile)**. Esto es similar a **Flujos de solicitud** de contacto, que solo se admiten en Experience Cloud. Independientemente del tipo de Flujo, la persona que crea el Flujo no tiene control sobre dónde está integrado el Flujo. Los flujos están disponibles en cada ubicación donde se admite ese tipo de flujo específico. Si está utilizando Salesforce Industries, hay una ligera advertencia cuando se trata de OmniScript.No puede especificar un objetivo para un OmniScript; sin embargo, puede especificar un objetivo para las FlexCards que desea integrar. ### Automatización de pruebas de la interfaz de usuario En Salesforce, existen varias herramientas de automatización de pruebas de extremo a extremo (por ejemplo, consulte [UTAM de Salesforce](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)) que le permiten simular cómo interactúa un usuario con sus formularios. Puede redactar pruebas para cualquier interfaz de usuario estándar o personalizada, incluyendo páginas Lightning y Flujos de pantalla. **Nota:** Estos tipos de pruebas no pueden verificar los resultados de los métodos que se están realizando. Tenga esto en cuenta cuando configure sus requisitos de automatización de pruebas de la interfaz de usuario. #### Preguntas para formular - ¿Necesita pruebas automatizadas para sus formularios? - ¿Qué tipos de pruebas tiene intención de realizar? - ¿Qué nivel de granularidad es necesario para las automatizaciones de pruebas?
Pruebas de unidad Automatización de extremo a extremo
Formularios dinámicos No disponible Disponible*
Flujo de pantalla No disponible Disponible*
Omnistudio Disponible* Disponible*
Flujo de pantalla + LWC Disponible* Disponible*
LWC Disponible Disponible
*Requiere código
**Considerar requisitos de automatización de pruebas de interfaz de usuario** Las **pruebas de unidades** proporcionan una automatización y validación granulares que se alinean con herramientas y sistemas de CI/CD estándar de la industria, que prueban la lógica de negocio, los controles de JavaScript y los resultados de componentes específicos. Si elige un enfoque de código bajo, no podrá realizar pruebas de autoría; sin embargo, Salesforce prueba rigurosamente todas las ofertas de extremo a extremo. Si los métodos de su componente son complejos, puede enviarlos por mensaje de texto individualmente colocando los métodos en archivos JavaScript exclusivos. Esto le permite importarlos en un LWC y luego en una **prueba Jest (por ejemplo**, importar { sort } desde 'c/utils';). Puede utilizar una solución sin código desde un ISV, crear una solución de automatización de pruebas personalizada o utilizar un marco de trabajo de prueba de código abierto (por ejemplo, Selenium WebDriver o WebdriverIO) para la automatización de extremo a extremo. Estas soluciones son válidas para todas las interacciones de la interfaz de usuario de Salesforce (por ejemplo, un Formulario dinámico en una página Lightning, un Flujo de pantalla en una barra de utilidades o un LWC en un Flujo de acción rápida). ### Mediciones Después de implementar su formulario en un entorno de producción, debe asegurarse de que se está utilizando de forma efectiva. Dependiendo de su caso de uso, esto puede significar realizar un seguimiento del número de veces que se completó su formulario hasta la cantidad de tiempo que el usuario medio emplea en completar el formulario antes de enviar su información. Es importante identificar sus KPI con capacidad de seguimiento antes de seleccionar una herramienta. #### Preguntas para formular - ¿Necesita realizar un seguimiento del uso de formularios? - ¿Qué indicadores clave de desempeño pueden determinar si el formulario se está utilizando de forma efectiva?
Vistas de página Tiempo empleado en el formulario Realizar seguimiento de la cumplimentación de formularios Realizar un seguimiento del índice de éxito
Formularios dinámicos Disponible** No disponible No disponible No disponible
Flujo de pantalla Disponible Disponible* Disponible Disponible
Omnistudio Disponible Disponible* Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible* Disponible Disponible
LWC Disponible** Disponible* Disponible Disponible
*Disponible cuando Tiempo de ejecución de OmniStudio basado en paquetes está activado** Disponible realizando un seguimiento del uso de la página Lightning principal
Si necesita realizar un seguimiento del uso y la adopción de formularios en general, utilice herramientas de código bajo. Los flujos de pantalla y formularios dinámicos son rastreables a través de reportes personalizados listos para su uso. Sin embargo, los reportes de seguimiento de Flujo de pantalla proporcionan granularidad adicional. Si necesita realizar un seguimiento del uso de LWC, la disponibilidad de uso inmediato depende de dónde esté utilizando el LWC. Si está en una página Lightning, todos los elementos de seguimiento de uso de página Lightning disponibles también se aplican a su LWC. Esto también es cierto para LWC incrustados en flujos. Los Formularios dinámicos no tienen capacidad de seguimiento de uso inmediato; sin embargo, puede realizar un seguimiento del uso de la página Lightning principal a través de [objetos de uso Lightning](https://help.salesforce.com/articleView?id=lex_usage_reports.htm). Para realizar un seguimiento de páginas Lightning estándar, utilice el reporte personalizado **Usuarios con Lightning Usage by Page Metrics**. Para páginas Lightning personalizadas, utilice el reporte personalizado **Usuarios con Lightning Usage by FlexiPage Metrics**. Los flujos pueden ayudarle a realizar un seguimiento de la adopción de formularios específicos. Utilice el reporte de flujo de **muestra: Flujos** de pantalla para responder a estos tipos de preguntas: - ¿Cuál es el índice de realización de este formulario? ¿Está actualmente bien adoptado? - ¿Cuánto tardan los usuarios en rellenar este formulario? - ¿Qué pantalla emplean los usuarios más tiempo en completar? - ¿Con qué frecuencia navegan los usuarios a pantallas anteriores? - ¿Con qué frecuencia se producen errores? Si el reporte estándar no cumple sus necesidades, puede duplicarlo y realizar cambios o Build Your Own Report desde cero utilizando el reporte **Flujos de pantalla**. Si está utilizando el tiempo de ejecución de OmniScript basado en paquetes, también puede utilizar [OmniStudio para Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). Este servicio realiza un seguimiento de todos los tipos de eventos (por ejemplo, puede realizar un seguimiento del tiempo que tarda en completar los pasos en un OmniScript, lo que ayuda a identificar mejoras en los procesos). **Nota:** No hay una opción lista para su uso para realizar un seguimiento de un LWC que no esté integrado en una página Flujo de pantalla, OmniScript o Lightning, pero puede crear una solución personalizada utilizando Apex. ### Empaquetado e implementación Es posible que esté familiarizado con el uso de conjuntos de cambios o **DevOps Center** para implementar su solución en entornos de prueba o en producción. Estas opciones de implementación admiten completamente Formularios dinámicos, Flujos y LWC. Sin embargo, OmniStudio requiere una herramienta separada, el [Sobremesa de trabajo IX](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5). #### Preguntas para formular - ¿Cómo piensa implementar el formulario? - ¿Necesita distribuir el formulario a más de una organización de Salesforce?
Paquetes gestionados de primera generación (1GP) Paquetes gestionados de segunda generación (2GP) Paquetes desbloqueados Conjuntos de cambios DevOps Center
Formularios dinámicos Disponible Disponible Disponible Disponible Disponible
Flujo de pantalla Disponible Disponible Disponible Disponible Disponible
Omnistudio No disponible No disponible No disponible No disponible* No disponible*
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible
LWC Disponible Disponible Disponible Disponible Disponible
*Utilice IDX Workbench para implementar Soluciones de OmniStudio en otras organizaciones.
Si es un ISV o un socio que planea empaquetar su solución para su distribución en AppExchange, consulte Formularios dinámicos, Flujos y LWC. Recuerde que OmniStudio no admite el empaquetado. ### Navegar por el continuo de código bajo a código pro Esta guía pretende mostrarle qué funciones y niveles de personalización están disponibles a través de Formularios dinámicos, flujos de pantalla, OmniStudio y LWC. Low-Code to Pro-Code Continuum A continuación se incluye una descripción general de alto nivel. - Cuando se trata de crear formularios, LWC es la opción más sólida y personalizable, pero tiene el menor número de salvaguardas. Por eso es crucial crear sus componentes teniendo en cuenta la [seguridad](/docs/architect/es-mx/well-architected/guide/trust.html) y [la escalabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html#scalability-and-capacity-planning). - Formularios dinámicos es la opción menos flexible, pero tiene muchas menos oportunidades de pasos en falso. - Flujo y OmniEstudio caen ligeramente en el medio. Son más potentes que Formularios dinámicos, pero no están a la altura del nivel LWC. Sin embargo, tienen menos barandillas que Formularios dinámicos y son más difíciles de romper que el código personalizado. Es posible que descubra que varias herramientas se ajustan a sus necesidades. Si es así, la decisión depende en última instancia de qué herramienta es la mejor para su equipo. Para obtener más información sobre aspectos adicionales a tener en cuenta, consulte estas [Guías de decisiones](/docs/architect/es-mx/decision-guides) de arquitecto. #### Preguntas para formular - Cuando compara herramientas, ¿es importante evaluar cuánta experiencia tiene su equipo con respecto a cada herramienta? - ¿Cuántos de sus desarrolladores están bien versados en LWC o JavaScript? - ¿Hay desarrolladores en su equipo que sean expertos en Flow Builder o que hayan expresado interés en aprender más? Aunque no entraremos en detalles específicos, a continuación encontrará un poco más de información sobre cómo se relacionan estas herramientas específicas con las evaluaciones que hemos cubierto hasta ahora. **Delegación de entrega** Tenga en cuenta que incluso si algunos de sus requisitos requieren LWC, no requiere que toda la solución se cree utilizando LWC. Es importante determinar cómo puede crear su solución de forma modular. Para ello, debe identificar qué piezas requieren LWC codificado y qué piezas no. Las piezas que no requieren LWC deben construirse utilizando una solución de código bajo. Cuando se trata de Flujo y LWC, existen varios componentes (por ejemplo, Componentes de pantalla reactivos y Flujo de pantalla) que pueden sincronizarse entre sí en la misma pantalla para desbloquear nuevas herramientas para arquitectos, administradores y desarrolladores. Los desarrolladores ahora pueden crear componentes modulares específicos que se pueden reutilizar en toda la organización, lo que ayuda a potenciar la productividad del equipo. Esto permite a los desarrolladores ahorrar tiempo utilizando una mezcla de componentes Flujo estándar y personalizados para lograr el dinamismo de las formas, lo que les da más tiempo para centrarse en resolver nuevos retos. Con la introducción de Componentes reactivos en Flujo, nunca ha habido un momento más apropiado para mezclar Flujo y LWC al crear formularios. **Propiedad y mantenimiento a largo plazo** Si está creando un formulario de múltiples pasos, comience con Flujo o una mezcla de Flujo y LWC. Si el equipo que está manteniendo el formulario es un equipo de código bajo, asegúrese de que la solución es lo más configurable y ampliable posible para su audiencia prevista. Para mejorar la estabilidad y la capacidad de mantenimiento, es importante organizar su solución en unidades [componibles](/docs/architect/es-mx/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity), independientemente de la herramienta que seleccione. ### Desempeño Las consideraciones de desempeño relacionadas con Formularios dinámicos, Flujos de pantalla, OmniStudio o LWC se basan en el marco de trabajo donde se alojan las tecnologías. Las tecnologías basadas en LWC tienden a superar a las basadas en Aura. Debido a varias funciones principales implementadas de forma nativa en motores web (en vez de en JavaScript a través de abstracciones de marco de trabajo), el LWC proporciona beneficios de desempeño mejorados. Por lo tanto, ¿cómo aprovechamos estos beneficios de desempeño para nuestras tecnologías de formularios en Salesforce? Echemos un vistazo más de cerca. - Formularios dinámicos (integrados en metadatos de páginas Lightning) está construido sobre una base de pila de LWC, lo que nos permite implementar varias funciones muy esperadas. Como ventaja de desempeño adicional, Formularios dinámicos utiliza la representación progresiva, lo que mejora el tiempo de carga para páginas que tienen un gran número de campos. - Los flujos de pantalla se crean sobre LWC. La mayoría de los componentes individuales listos para su uso se convirtieron ahora a LWC con la excepción de los componentes **Carga de archivos** e **Imagen**. Aunque el equipo de Flujo convirtió el cliente de tiempo de ejecución de flujo a LWC (y la mayoría de sus componentes), los clientes aún necesitan convertir sus componentes de pantalla Aura a LWC. Recuerde que Salesforce solo admite componentes LWC en el marco de trabajo **Componente reactivo** en Flujos de pantalla. Para obtener más información, consulte el módulo Trailhead [Componentes web Lightning para](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) desarrolladores Aura. Si está considerando crear un componente personalizado para un flujo de pantalla (o cualquier otro contenedor), seleccione LWC. - Existen varias versiones de OmniStudio disponibles. Si es un cliente de larga data, es posible que esté utilizando **Angular**. Animamos a todos los nuevos clientes a utilizar FlexCards y OmniScripts basados en LWC. También animamos a los clientes existentes a migrar fuera de Angular. - LWC se basa en LWC. ## Recursos
Formularios dinámicos - Dividir sus detalles de registro con formularios dinámicos
- Obtener ayuda para Lightning App Builder
Flujo de pantalla Utilizar flujos de pantalla para interactuar con usuarios
- Automatizar tareas con flujos
Omnistudio Omnistudio
- OmniScripts
- Aplicación de escritorio IDX Workbench
- Sistema de diseño Newport
Personalizar OmniScripts y Flexcards con el Sistema de diseño Newport
LWC - Componentes web Lightning
Guía del desarrollador de componentes Lightning Aura
- Componentes web Lightning para desarrolladores Aura