¿Está buscando crear formularios en Salesforce Platform? Tiene múltiples opciones, que abarcan todo el código bajo al continuo de código profesional. Representan códigos bajos Formularios dinámicos en el Generador de aplicaciones Lightning y flujos de pantalla en Flow Builder. Pasar el rato en medio del continuo es la capacidad de ampliar flujos de pantalla con LWC y crear formularios de cara al cliente con OmniStudio. Además, representando pro-código está el marco de trabajo LWC y su biblioteca en constante crecimiento de componentes base.

Las opciones son excelentes, pero ¿cómo determinar cuál (o qué combinación) es la opción correcta? Ahí es donde entra esta guía.

• Llevada # 1: Al crear/modificar/ver formatos para páginas Lightning, utilice Formularios dinámicos. Es posible que observe que faltan formatos de página en las tablas de comparación de esta guía. En adelante, la forma recomendada de configurar páginas de detalles de registros es utilizar Formularios dinámicos en el Generador de aplicaciones Lightning. Consulte la sección sobre Formatos de página para obtener más información acerca de por qué no esperamos mejorarlos aún más.
• Conclusión # 2: Si necesita crear o modificar un formulario para exactamente un objeto, comience con páginas Lightning y Formularios dinámicos. Esta es la forma más sencilla de crear formularios en Salesforce Platform. También proporciona algunas funciones adicionales, como la capacidad de controlar la visibilidad del campo. Si sus requisitos son más avanzados, siga leyendo. Flujo de pantalla, OmniStudio o Componentes web Lightning (LWC) pueden ajustarse mejor.
• Conclusión #3: Si está creando un formulario de varias páginas o un asistente y no tiene requisitos estrictos de marca o UX, comience con un Flujo de pantalla. Los flujos de pantalla proporcionan un marco de navegación lineal para orquestar múltiples formularios juntos. Puede utilizar LWC para crear su propio marco de trabajo para navegar entre formularios, pero recomendamos dejar que Flow haga el trabajo duro por usted, de modo que pueda centrarse en los formularios en sí en vez de preocuparse por el estado del formulario.
• Conclusión #4: Si necesita lógica o acciones adicionales detrás del formulario, utilice un Flujo de pantalla, OmniStudio o LWC. Las tres herramientas ofrecen formas para que su solución haga más que crear o modificar un único registro. Ese “más” podría ser una lógica más avanzada, como la bifurcación o la iteración, o podrían ser más acciones como la integración con sistemas externos, el envío de correos electrónicos o el envío de notificaciones a la aplicación móvil de un usuario.
• Conclusión #5: ¿Tiene requisitos de UX sofisticados? ¿Necesita gestionar de forma dinámica algo más que visibilidad? Utilice LWC u OmniScript. Si sus requisitos se pueden lograr con formatos basados en columnas y temas sencillos, puede crear sus formularios directamente en un generador de código bajo. Para un control más preciso sobre el estilo de su formulario, necesitará la flexibilidad definitiva 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 permitirá crear formularios de categoría de consumidor que pueden gestionar transformaciones de datos y lógica comercial complejas.
• Para llevar #6: Si necesita automatización de pruebas, comience con Componentes web Lightning. Puede redactar pruebas de unidad para cualquier LWC, independientemente de dónde planee integrarlo. Esto le proporciona la capacidad de crear una estrategia de prueba más sólida, que puede incluir pruebas masivas con múltiples registros y pruebas negativas. Consulte Salesforce Well-Architected - Testing Strategy para obtener más información acerca de la creación de pruebas que le ayudarán a ver cuán bien se alinearán sus formularios con sus requisitos funcionales y no funcionales.

Tenga en cuenta que su elección no tiene que ser una opción o puede combinar el poder de múltiples opciones. Por ejemplo, si necesita el sistema de navegación integrado de Flow y la flexibilidad de estilo completa que ofrece LWC, utilícelos juntos.

La tabla siguiente describe las herramientas disponibles para crear formularios con Salesforce, junto con sus habilidades requeridas y consideraciones de licencia. Más adelante profundizaremos en las funciones específicas compatibles con cada herramienta, así como en cómo elegir entre herramientas basadas en clics y herramientas basadas en código (y cuándo combinarlas):

La tabla siguiente contiene una descripción general de los puntos de decisión en los que pensar al realizar sus selecciones de productos, junto con preguntas que debe hacerse acerca de cada uno. Profundizaremos en cada uno de estos temas a lo largo del resto de esta guía.

Estos son los términos que utilizamos en las tablas de comparación junto con sus definiciones:

• Disponible: Funciona bien con consideraciones básicas.
• No es ideal: Puede funcionar pero no es la herramienta óptima.
• Hoja de ruta: Apoyo estimado en los próximos doce meses (junio de 2025).
• Futuro: Estimación de asistencia más allá de los próximos doce meses.
• No disponible: No hay planes para admitir esta función en los próximos doce meses.

Como se prometió, comencemos a profundizar en una variedad de puntos de comparación y diferencias funcionales entre Formularios dinámicos, Flujos de pantalla, OmniStudio, Flujos de pantalla con LWC integrados y el marco de trabajo de LWC en sí.

Si su formulario opera con un único objeto de Salesforce, cualquiera de las herramientas que estamos comparando funcionará. Las cosas se complican un poco con formas de objetos cruzados o que distinguen entre objetos. Por objetos específicos, nos referimos a entradas que no se asignan a ningún objeto de Salesforce. Quizás su formulario representa una estructura de datos que enviará a un servicio externo, como Stripe o DocuSign. O quizás está utilizando varias entradas en su formulario para calcular un valor y luego confirmar ese valor en la base de datos.

• ¿Contra qué objetos operará el formulario?
• ¿Es solo un objeto o hay múltiples objetos?
• ¿Está trabajando con objetos específicos (por ejemplo, Cuenta, Contacto, Oportunidad, Candidato y Caso) o su formulario también tendrá que funcionar con otros objetos?

Tanto para formularios de objeto cruzado como para formularios que distinguen entre objetos, Flow y OmniStudio son opciones sólidas. Los componentes disponibles en pantallas de flujo son agnósticos por naturaleza, de modo que puede elegir qué hacer con esos datos en segundo plano. Por ejemplo, utilice los datos introducidos en un formulario para crear múltiples registros en segundo plano o utilice los datos para realizar otras acciones como generar publicaciones Chatter, enviar mensajes de Slack, enviar correos electrónicos o conectarse a servicios externos.

Para casos sencillos, el uso de componentes LWC existentes, como Lightning, puede ser una forma sencilla de reducir el código necesario para proporcionar una solución sólida. Sin embargo, para escenarios donde están implicados múltiples objetos, Flow proporciona un control integral para todos los objetos y elimina la necesidad de que los desarrolladores atraviesen relaciones y dependencias complejas.

OmniStudio lleva las cosas un paso más allá y es completamente consciente de los objetos: separa la forma que ve un usuario del modelo de datos subyacente. En su lugar, OmniStudio manipula JSON subyacente que luego se asigna a objetos de Salesforce (o datos externos) utilizando herramientas como Asignador de datos y Procedimientos de integración. Asignador de datos y Procedimientos de integración son dos componentes clave para conectar sus formularios de OmniStudio con datos internos y externos a Salesforce. Utilizando elementos de arrastrar y soltar, puede trabajar con datos jerárquicos complejos en un sistema externo y luego transformar los datos para ajustarse a sus necesidades dependiendo de dónde necesitan ir los datos. También le permiten utilizar fórmulas para realizar operaciones matemáticas y lógica en matrices o listas de datos, como Apex.

Integraciones de OmniStudio

Si puede obtener todas sus entradas de usuario desde un formulario de pantalla única, comience con Formularios dinámicos. Sin embargo, aunque Formularios dinámicos en páginas de registro puede utilizar la función Ruta para representar libremente las diversas etapas en su proceso comercial, es posible que no se ajuste a la mayoría de sus casos de uso.

• ¿Necesita una única 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 de rellenar su formulario?
• ¿Se requerirá a sus usuarios rellenar la información en cada pantalla en un orden específico o deberían 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 Flow, OmniStudio y LWC dependerá también de algunas otras preguntas:

• ¿Qué habilidades tiene su equipo? Para una organización más pesada de administradores, recomendamos comenzar con Flujo. Si tiene soluciones de Industries, su equipo ya está familiarizado con OmniStudio y su proyecto tiene estrictos requisitos de UX, comience con OmniStudio.
• ¿Está bien mostrar una barra de navegación en la parte inferior de su formulario? Si el flujo de pantalla y la experiencia de navegación de OmniScript no son deseables, inclínese hacia LWC.
• ¿Qué debe ocurrir detrás del formulario? Si necesita que el comportamiento sea configurable por un administrador, cree un flujo o, para cambios básicos como el cambio de etiquetas de campo, un OmniScript. De lo contrario, para relaciones complejas de múltiples objetos, cree un OmniScript o LWC.
• Si elige Flow u OmniStudio, es posible que tenga que crear un LWC de todos modos para alcanzar el UX correcto. Si ya está creando un LWC para diseñar su formulario correctamente, considere si integrar ese componente en un flujo es exagerado.

Si, por el contrario, su solución tiene el aspecto de un asistente, donde el usuario navega entre múltiples pantallas, considere Flow u OmniStudio. Flows 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. Para obtener un excelente ejemplo del uso de flujos de pantalla, consulte el paquete Auditoría de establecimiento digital de Salesforce Labs.

OmniStudio ofrece una ventaja de navegación clave proporcionando indicadores de progreso desde la navegación estándar que aflora "pasos" en el formulario. Esta vista de paso muestra automáticamente dónde está un usuario en un formulario de múltiples pasos concreto. A diferencia de Flujo, permite a los usuarios “saltar” entre pantallas haciendo clic en varios pasos del formulario.

Independientemente de si está creando formularios de pantalla única o múltiples pantallas, asegúrese de que sus formularios están simplificados de modo que sean fáciles de navegar para sus usuarios.

Si está incrustando un formulario en una página de registro Lightning estándar, cualquiera de las herramientas que estamos comparando funcionará, con la advertencia de que Formularios dinámicos solo está disponible actualmente en el escritorio. Sin embargo, si está buscando proporcionar una experiencia que permita a los usuarios acceder a formularios desde otras ubicaciones, es posible que tenga que considerar opciones alternativas.

• ¿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 utilizar 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?

Dado que requieren contexto de registro, Formularios dinámicos solo se admiten en páginas de registro Lightning. Sin embargo, Formularios dinámicos no es compatible en páginas de Experience Cloud. Esta limitación está vigente porque Experience Cloud no utiliza el marco subyacente del que dependen Formularios dinámicos: Páginas Lightning. Estamos evaluando esto basándose en solicitudes de Formularios dinámicos en Experience Cloud.

Puede crear flujos que requieren un contexto de registro o flujos que funcionan de forma global. Como tal, puede integrar flujos en una variedad de ubicaciones. Para flujos contextuales de registro, puede ser una página de registro Lightning, una página de registro de Experience Cloud, una acción específica de objeto o una implementación de Acciones y recomendaciones. Para el flujo global, esa podría ser la barra de utilidades, otras páginas Lightning o Experience Builder, un Snap o una aplicación externa. Los flujos no se admiten actualmente como acciones globales, pero como solución puede incluir el flujo en un componente Aura.

OmniStudio le permite crear FlexCards y OmniScripts componibles que puede colocar casi en cualquier lugar donde pueda poner un flujo. Sin embargo, aunque se pueden componer, no se pueden empaquetar.

LWC admite un alto grado de reutilización, ya que está creando componentes que se pueden asociar con objetivos a través de metadatos en Salesforce, Comunidades e incluso en proyectos de código abierto. Los componentes LWC también se pueden integrar en su propio sitio web a través de Lightning Out.

Lightning Out en sitios externos

Los componentes web Lightning no se admiten actualmente como acciones rápidas (específicas de objetos o globales), pero como solución puede incluir un LWC en un componente Aura (al igual que con flujos). Los componentes LWC también pueden iniciar flujos con el componente Lightning flow.

OmniStudio destaca en la exposición de contenido a sus 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 ejecutarlos fuera de la plataforma en sitios o aplicaciones externos.

Ninguna de las tecnologías de formularios cubiertas en esta guía es compatible oficialmente en plantillas de Mobile SDK hoy. Si Mobile SDK es esencial para su caso de uso, es mejor que cree su formulario de forma nativa en su aplicación móvil o cree una página Visualforce, teniendo en cuenta las directrices de factores de forma bien arquitectónicas de Salesforce.

Nota de hoja de ruta: El equipo de Mobile SDK está trabajando activamente en la asistencia a LWC en páginas Visualforce.

Formularios dinámicos es perfecto si necesita utilizar los valores de su formulario para crear o actualizar un registro. Para cualquier función más allá de eso, tendrá que aprovechar Flow, OmniStudio o LWC. Esas funciones podrían incluir una capa de decisión o iteración, o la generación de publicaciones o correos electrónicos de Slack utilizando las entradas del formulario.

• ¿Qué acciones o lógica desea que se realicen en segundo plano?
• ¿Contiene su modelo de datos datos datos jerárquicos?
• ¿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?

Flow ofrece acciones estándar para publicar en Slack, enviar correos electrónicos e interactuar con documentos Quip, de modo que no tiene que escribir código para estas operaciones. LWC ofrece interacciones enriquecidas con registros únicos y objetos relacionados a través del uso de adaptadores de cable que interactúan con la API de interfaz de usuario. LWC también puede interactuar con múltiples registros al utilizar el cable para getListInfoByName.

Interacción Lightning Web Components a través de adaptadores de cable

Como se mencionó anteriormente, OmniStudio utiliza Procedimientos de integración y Asignador de datos para capturar y transformar fácilmente datos externos e internos en Salesforce. Brilla en el aplanamiento y la ampliación de conjuntos de datos con varios niveles de relaciones gracias a numerosas funciones sin código que puede utilizar.

Nota de hoja de ruta: Flow pronto admitirá la capacidad de alterar recopilaciones de registros, así como gestionar datos jerárquicos.

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 requiere filtrar registros desde un LWC, siempre puede utilizar el adaptador de cable para Apex para crear consultas SOQL complejas. Si se deja influir por la historia basada en clics, considere Flow u OmniStudio como alternativas viables a un controlador Apex para sus necesidades del lado del servidor.

Una pregunta secundaria aquí es si desea confirmar acciones inmediatamente o aplazarlas a una parte concreta de su formulario. Esto es especialmente relevante si está en un formulario de varias páginas. El flujo facilita la combinación de entradas desde múltiples formularios (pantallas de flujo) y su uso mucho más adelante en el asistente (flujo) para realizar algunas operaciones. De hecho, recomendamos diseñar flujos justo de esa forma (realizar acciones al final) en caso de que el usuario rebote de un lado a otro entre pantallas, cambiando sus respuestas.

Las transacciones y los límites reguladores son una forma de vida en Salesforce Platform. Si su caso de uso es bastante sencillo, es posible que no sea tan importante controlar en qué transacción 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 única transacción en vez de realizarlas entre múltiples transacciones. Algunos ejemplos:

• Para revertir o no revertir: Esa es la cuestión. Supongamos que su formulario crea múltiples registros en segundo plano. Si no se crea el tercer registro, ¿se deben revertir los dos primeros registros? Si cada una de sus acciones es independiente entre sí, no dude en ejecutarlas en transacciones separadas. Sin embargo, si son dependientes y desea que el fallo de uno también revierta los otros, impleméntelos en una sola transacción. Si su formulario está en Flujo, puede utilizar el elemento Reversión en una ruta de fallo para revertir su transacción y garantizar la integridad de los datos.
• Repercusión descendente en los límites reguladores: Especialmente cuando su formulario crea o actualiza un registro, considere 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 en el orden de guardado se van a activar basándose en este cambio de registro? ¿Y cómo afectan esos cambios colectivos a los límites reguladores que se consumen en esa transacción? Si un cambio de registro concreto dará como resultado muchos cambios descendentes que afectarán a sus límites, considere aislar ese cambio de registro en su propia transacción.
• Procesamiento por lotes: Incluso en un contexto de interfaz de usuario, es posible que tenga que realizar múltiples actualizaciones por lotes. 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 neta nueva.

Al crear un flujo de pantalla, tiene un control significativo sobre lo que sucede 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 flujos de pantalla.

1. El usuario final interactúa con una pantalla y luego hace clic en Siguiente.
2. El cliente publica una solicitud en la API con las entradas.
3. La API recibe la solicitud y se 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 de flujo, hasta que alcanza un nodo Pantalla o 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 en la base de datos (por ejemplo, la ejecución del pedido 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 para que el usuario interactúe.
7. Repita el paso 1.

En otras palabras, las pantallas “rompen” transacciones. Cuando eso sucede, se confirma cualquier acción pendiente o DML, se cierra la transacción anterior y se inicia una nueva transacción.

El diseño correcto, qué operaciones agrupa en una transacción concreta, es su llamada. Veamos algunos ejemplos.

A la izquierda, puede ver un flujo que recopila entradas entre múltiples pantallas y luego realiza varias acciones en una transacción.

El flujo de la derecha realiza cada operación en una transacción separada.

Supongamos que tiene un flujo que crea registros, actualiza registros y luego crea más registros, como se ilustra en el siguiente flujo a la derecha.

En este escenario, si los dos primeros elementos tienen éxito y el último falla, las dos primeras operaciones DML seguirán creando y actualizando esos registros mientras que la tercera no.

Utilizando el elemento Revertir registros, puede garantizar que se revierte toda la transacción si las tres operaciones tienen que producirse en tándem, como se ve en el flujo final a la izquierda.

Para obtener más detalles, consulte Flujos en transacciones y Flujo masivo en transacciones. La sección Automatizado de Salesforce Well-Architected también profundiza más sobre esto en Gestión de datos.

Su capacidad para controlar la transacción desde un LWC se reduce a los servicios subyacentes que LWC está utilizando para realizar sus operaciones. Si está utilizando el componente base de formulario de registro Lightning, la operación subyacente (creación o actualización del registro) se produce en una transacción independiente en cuanto 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, como un controlador Apex o un flujo. Se aplican las reglas de transacción regulares para esa tecnología.

Flow, OmniStudio y LWC admiten eventos de plataforma (para arquitectura dirigida por eventos) e integraciones de API. Además del código Apex personalizado, tanto Flow como OmniStudio admiten mecanismos declarativos para integrar una API.

Si necesita conectarse a una API de Mulesoft o bot RPA, utilice Servicios de Mulesoft. Esto genera un Servicio externo.

Integraciones externas a través de API de Mulesoft y bots RPA

Si la API tiene un esquema de OpenAPI, cree un Servicio externo.

Integraciones externas en API con esquemas de OpenAPI

De lo contrario, utilice la función Llamada HTTP en Flujo o Acción HTTP en OmniStudio. La llamada HTTP de flujo funciona con Servicios externos.

Integraciones externas a través de HTTP

OmniStudio cuenta con un conjunto enriquecido de funciones de integración que pueden llamar a sistemas externos con Procedimientos de integración y transformar los datos con Asignador de datos. (Consulte Repercusión de objeto para obtener más información)

Independientemente de si lo implementa con Apex personalizado o un servicio externo, una llamada es una llamada. Esto es lo que necesita saber.

1. Una llamada puede tardar mucho tiempo.
2. Cuando una llamada se ejecuta de forma síncrona, se realiza mientras una transacción de base de datos está abierta.
3. Salesforce no le permite mantener una transacción de base de datos abierta si tiene operaciones de base de datos pendientes.

La principal limitación a tener en cuenta es el peligro de las llamadas transacciones sucias, donde realiza una operación de creación, actualización o eliminación y luego, en la misma transacción, ejecuta una llamada. Este patrón no está permitido debido a la consideración #3 anterior, que por supuesto existe debido a las consideraciones #1 y #2.

En Flujo, puede solucionar esta limitación rompiendo la transacción. Recuerde que las pantallas y las acciones locales reintroducen el contexto del navegador, lo que interrumpe la transacción. Aunque puede utilizar pantallas y acciones locales cuando trabaje con llamadas externas, recomendamos activar Control de transacciones en configuración avanzada invocable. Control de transacciones es una función de acciones invocables que le permite finalizar automáticamente la transacción antes de que se realice una llamada. Puede activar Control de transacciones seleccionando Iniciar siempre una nueva transacción en la sección Avanzado de una acción invocada.

Para obtener directrices más detalladas sobre llamadas Apex, servicios externos y funciones de integración de datos en general, consulte la Guía del arquitecto para la integración de datos con Salesforce.

Formularios dinámicos no admite la reutilización. Cada Formulario dinámico está vinculado a una página de registro Lightning específica para un objeto específico (aunque puede asignar esa página de registro Lightning a múltiples aplicaciones, perfiles, etc.).

Del mismo modo que puede redactar bibliotecas, utilidades y componentes pensados para su uso en múltiples otros componentes, puede aplicar patrones de diseño similares al crear flujos con la potencia de subflujos. Guarde sus flujos en depósitos más pequeños y modulares, y luego llámelos desde otros flujos utilizando el elemento Subflujo. Si su diseño lo requiere, puede crear un flujo que sea independiente y útil como subflujo de otro.

OmniStudio está construido de forma inherente para la modularidad. Los Asignadores de datos, OmniScripts, FlexCards y Procedimientos de integración se crean de forma independiente y pueden funcionar indistintamente. Además, las FlexCards se pueden crear como componentes de LWC que se pueden integrar en otros LWC, OmniScripts, páginas de registro y sitios de Experience Cloud.

Los flujos de pantalla, OmniScripts y 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, obtiene beneficios adicionales como adaptabilidad y estabilidad.

Todas las tecnologías que se utilizan para crear o actualizar un registro se adhieren a la validación a nivel del sistema, ya sean reglas de validación clásicas o validación personalizada integrada en un desencadenador Apex. Independientemente de la tecnología que utilice para realizar un cambio de registro, cada cambio pasa por el orden de guardado. Eso significa que además de las reglas de validación, el cambio de registro se procesa por cualquier número de flujos anteriores o posteriores al guardado, desencadenadores anteriores o posteriores, reglas de distribución, reglas de asignación y mucho más. Si aún no lo hizo, asegúrese de marcar y familiarizarse con el orden de ejecución de Apex.

• ¿Tiene su formulario requisitos adicionales más allá de la validación a nivel del sistema?
• ¿Necesitará establecer campos obligatorios o de solo lectura de forma dinámica en el formulario?

Las entradas en una pantalla de flujo o paso de OmniScript no están vinculadas por naturaleza, 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 utilice para crear o actualizar registros se procesan por el orden de guardado, lo que significa que pasan por la validación a nivel del sistema del objeto. Tenga en cuenta, sin embargo, que no todos los componentes de flujo de pantalla admiten la validación de entrada. A partir de Summer '24, los componentes de pantalla restantes que no admiten validación de entrada son Botones de opción, Lista de selección, Lista de selección múltiple, Grupo de casillas de verificación y Búsqueda de opción.

Al igual que los formatos de página, Formularios dinámicos le permite establecer la obligatoriedad y el estado de solo lectura en el nivel de página. Sin embargo, no puede sustituir la configuración a nivel del sistema.

El flujo proporciona flexibilidad para personalizar la validación en las entradas de un formulario. Aunque algunas comprobaciones se realizan en el cliente (como marcar campos obligatorios que faltan o valores incompatibles), ninguna de las validaciones del lado del cliente impide que el usuario intente navegar. La validación real se produce en el servidor. Cuando un usuario hace clic en Siguiente, Flow envía las entradas al servidor para su validación. Si se devuelven entradas como no válidas, se bloquea la navegación y se muestra el error apropiado. El servidor valida las entradas comprobando:

1. La configuración de obligatoriedad de la entrada o si el valor introducido es compatible con el tipo de datos subyacente.
2. Validación personalizada en esa entrada: Varios componentes estándar (casilla de verificación, divisa, fecha, fecha/hora, área de texto largo, número, contraseña y texto) admiten la validación personalizada por pantalla. Proporcione una expresión de fórmula booleana y un mensaje de error para mostrar cuando no se cumpla la expresión de fórmula.
3. Validación personalizada en el componente subyacente: Si está creando un LWC personalizado para un flujo, agregue su propio código de validación al método validate().

OmniStudio cuenta con gestión de validación y errores enriquecidos a través de la acción Establecer error en combinación con Vistas condicionales y el componente Mensajería.

En el lado de LWC, la mayoría de los componentes base realizan sus propias validaciones del lado del cliente. Por ejemplo, Lightning respeta la exigencia a nivel del sistema, pero no la exigencia a nivel de página. Para sus componentes personalizados, puede Build Your Own mecanismos de validación.

Los campos que requieren que los usuarios introduzcan datos deben aparecer pronto en sus formularios. Siempre que sea posible, valide entradas de usuario en el lado del cliente antes de enviar formularios. Para obtener más prácticas recomendadas sobre la simplificación de sus formularios, consulte las directrices de formularios en Salesforce Well-Architected - Engaging.

La seguridad es un tema complejo en general, y cuando se trata de crear formularios, hay una serie de consideraciones en las que podría ni siquiera haber pensado. En el nivel fundacional, querrá asegurarse de que el formulario se ejecuta en el contexto correcto y que los usuarios tienen los permisos que necesitan para trabajar con sus datos subyacentes. Pero más allá de eso, 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 puedan acceder al formulario en absoluto o poner limitaciones en los tipos de lugares donde los administradores pueden integrar el formulario en el futuro. Asegúrese de documentar sus requisitos de seguridad minuciosamente antes de elegir una herramienta. La Plantilla de política de seguridad bien arquitectada de Salesforce contiene directrices para este tipo de documentación.

• ¿Debe el formulario comprobar el acceso del usuario antes de realizar ciertas operaciones?
• ¿Debería desinfectar las entradas de usuario?
• ¿Desea controlar quién puede acceder al formulario?
• ¿Desea controlar dónde se puede incrustar el formulario?

Cuando algo se ejecuta en contexto de usuario, Salesforce aplica una serie de comprobaciones de acceso, incluyendo la verificación de la seguridad a nivel de campo, permisos CRUD y 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. Pero, ¿qué sucede si desea que los usuarios puedan realizar una operación en particular cuando están utilizando su formulario, pero no a través de cualquier otro formulario o interacción? Ahí es donde entra el contexto del sistema.

El contexto del sistema es una forma de elevar los permisos del usuario que ejecuta durante la sesión, de modo que el usuario no necesita, por ejemplo, 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 que se ejecute en contexto del sistema.

Por supuesto, el contexto del sistema es una espada de doble filo y debe utilizarla solo cuando sea necesario. Cuando un formulario se ejecuta en contexto del sistema, cada operación CRUD omite la seguridad y colaboración a nivel de objeto y campo, no solo la operación específica que le importa. Tenga en cuenta también que el contexto del sistema no tiene relación con quién considera Salesforce el actor, el nombre que ve en el campo Última modificación por. Para cada operación que realice su formulario, como la actualización de caso, el actor es el usuario que ejecuta incluso si el formulario se ejecuta en un contexto diferente.

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. Es su elección si el flujo debe otorgar acceso a todos los datos o si aún debe aplicar acceso a nivel de registro como colaboración.

• Si incrusta un componente Lightning en un flujo que se ejecuta en contexto del sistema, el flujo no sustituye el contexto del componente. Si necesita omitir las comprobaciones de acceso de usuarios, recomendamos utilizar el flujo para realizar esas operaciones y pasar los datos apropiados dentro o fuera del componente Lightning. Algunos componentes listos para su uso (como Búsqueda) no pueden operar en contexto del sistema.
• Si su flujo llama acciones Apex, hay algunos matices más que comprender. Si la clase Apex está establecida como colaboración heredada, se ejecuta en contexto del sistema con colaboración independientemente de cuál sea el flujo establecido. Si la clase no tiene ninguna declaración de colaboración explícita, se ejecuta en contexto del sistema sin colaboración independientemente de cuál sea el flujo establecido. Si la clase está establecida como con colaboración o sin colaboración, lo hace y sustituye el contexto del flujo.

Consulta de 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 no autenticado, recomendamos almacenar 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 subflujo, una acción invocable o un componente Lightning, todos los campos de ese objeto se pueden inspeccionar a través de las herramientas de desarrollador del navegador. Esto podría hacer que los campos estén disponibles para los usuarios de su sitio de Experience Cloud que no pretenda. Especificando campos específicos en sus elementos Obtener registros, puede asegurarse de que solo se exponen los campos correctos incluso con contexto del sistema activado.

Tenga en cuenta que 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 utilizando las herramientas de desarrollador del navegador. Cuando utilice OmniScript, recomendamos ejecutar lógica comercial en el lado del servidor siempre que sea posible e implementar reglas de validación de entrada en cualquier método Apex expuesto a través de una anotación @InvocableMethod.

Insumos de desinfección:

Para proteger su organización de malos actores, considere también la desinfección de entrada. Supongamos que tiene una entrada en un formulario accesible públicamente que podría asignarse a un campo Texto enriquecido en su organización. Es posible que desee considerar la automatización que elimina cualquier HTML que podría ocultar direcciones URL maliciosas. En general, no es ideal implementar esta desinfección a nivel de formulario, ya que podría tener cualquier número de orígenes escritos en estos campos. Recomendamos crear un flujo de actualización de campo rápida (antes de guardar) o utilizar un desencadenador Apex existente en el objeto para eliminar o modificar cualquier HTML potencial que se pueda introducir en el formulario.

Prácticas recomendadas:

• Deje que los flujos se ejecuten en su contexto predeterminado a menos que necesite elevar el acceso del usuario que ejecuta para una operación específica.
• Evite ejecutar flujos en contexto del sistema para usuarios invitados por motivos de seguridad. Cree conjuntos de permisos con acceso de campo limitado asignado al perfil de usuario invitado del sitio de Experience Cloud en su lugar.
• Cuando consulte registros en flujos ejecutados por contexto del sistema en sitios de Experience Cloud, almacene únicamente los campos que necesita en su elemento Obtener registros o Acciones invocables.
• Si un flujo realiza una variedad de operaciones y no todas requieren acceso elevado, utilice subflujos para aislar las operaciones que se deben ejecutar en contexto del sistema.
• Si planea integrar un formulario en una página web externa, considere desinfectar entradas de usuario para eliminar HTML utilizando un Flujo de actualización de campo rápida o Desencadenador Apex si eventualmente se asignarán a campos de Texto enriquecido para evitar cualquier posible ataque de phishing de actores incorrectos.

• OmniScripts, FlexCards y LWC se ejecutan en contexto de usuario de forma predeterminada.
• Los LWC se ejecutan en contexto de usuario de forma predeterminada y los flujos se ejecutan en contexto de usuario, pero puede sustituir eso en un controlador Apex.
• Las operaciones realizadas a través de la API de la interfaz de usuario se ejecutan en contexto de usuario.
• Las operaciones realizadas a través de un controlador Apex dependen de esa clase. Para realizar esas operaciones en modo sistema, establezca la clase Apex como con colaboración o sin colaboración.

Si necesita control sobre quién puede acceder a su formulario, a menudo puede buscar el contenedor en el que 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 algunas entradas de su formulario son confidenciales, utilice reglas de visibilidad para controlar más lo que se muestra a quién; esta función se aplica tanto a Formularios dinámicos como a flujos de pantalla.

Puede restringir un flujo a perfiles o conjuntos de permisos en particular, de la misma manera que puede hacer con una clase Apex o una página Visualforce. De forma predeterminada, los flujos no están restringidos, lo que significa que cualquier usuario con el permiso de usuario Ejecutar flujos puede ejecutarlos.

Si está utilizando OmniStudio, puede configurar un comprobador de permisos de clase Apex para garantizar que los usuarios requieren acceso explícito a la clase Apex que administra la acción remota llamada desde una API de OmniScript, Flexcard, Classic Card o REST.

• Nota Las comprobaciones de permisos de clase Apex están activadas de forma predeterminada para secuencias de comandos recién creadas. Sin embargo, tienen que activarse manualmente para cualquier secuencia de comandos existente
• Tenga en cuenta también que las comprobaciones de permisos de clases Apex solo se aplican a clases Apex. Recomendamos establecer permisos a nivel de perfil para Procedimientos de integración y Asignadores de datos también.

Para obtener más detalles y prácticas recomendadas sobre permisos de usuario invitado, consulte:

• Prácticas recomendadas de acceso a registros de usuario invitado
• Desarrollar sitios seguros: Usuarios autenticados e invitados

Prácticas recomendadas:

• Si está exponiendo un flujo a usuarios invitados, otorgue al perfil de usuario invitado acceso solo a los flujos que necesita. Aunque es posible agregar Ejecutar flujos al perfil de usuario invitado, consideramos que es una práctica arriesgada.
• Tenga especial cuidado con los flujos que funcionan en contexto del sistema. Recomendamos encarecidamente restringir esos flujos a un conjunto concreto de usuarios, ya que tienen menos controles y equilibrios establecidos para proteger sus datos.
• Asegúrese de que cualquier OmniScript que ejecuta Apex en una comunidad de usuarios invitados tiene "con colaboración" en la definición de clase Apex.
• En su perfil Usuario invitado, asigne solo aquellas clases Apex a las que desea que los usuarios invitados puedan llamar o corre el riesgo de exponer involuntariamente lógica comercial adicional a usuarios invitados.

Para LWC, puede comprobar las asignaciones de permisos del usuario que ejecuta para confirmar si tiene un permiso estándar o personalizado concreto. Directamente desde JavaScript, puede importar permisos de Salesforce desde los módulos con ámbito @salesforce/userPermission y @salesforce/customPermission. O bien puede utilizar Apex para comprobar lo mismo.

Los componentes web Lightning solo están disponibles en una ubicación determinada cuando se han agregado como un destino 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 donde se admiten los flujos de pantalla, independientemente de si pretendía que estuviera disponible en cualquier parte o no. Dicho esto, Flow Builder admite múltiples tipos de flujos que tienen pantallas. El tipo básico es Flujo de pantalla, pero hay otros tipos especializados restringidos a ubicaciones específicas. Por ejemplo, la aplicación móvil Field Service solo admite, lo adivinó, flujos móviles de Field Service. Lo mismo sucede con los flujos de solicitud de contacto, que solo se admiten en Experience Cloud.

Independientemente del tipo de flujo, la persona que realiza el flujo no tiene control sobre dónde se puede incrustar el flujo. El flujo estará disponible en cada ubicación compatible con ese tipo de flujo.

Si está utilizando Salesforce Industries, hay una ligera advertencia en lo que respecta a OmniScript: Aunque no puede especificar un destino para un OmniScript en sí, puede especificar uno para las FlexCards que desea integrar en él.

Las formas estáticas son cosa del pasado. Hoy en día, se trata de actualizar dinámicamente el formulario con las propiedades y valores correctos para este usuario, esta vez, este lugar. Hablemos de lo que es posible en esta línea para las herramientas de creación de formularios de Salesforce.

• ¿Qué tipos de interacciones o condiciones deben desencadenar respuestas dinámicas en su formulario?
• ¿Necesitará ejecutar operaciones fuera de pantalla en segundo plano cuando se rellene su formulario?
• ¿Necesitará establecer campos como visibles, obligatorios, de solo lectura o desactivados o cambiar el formato basándose en entradas de formulario?

La interactividad de flujos de pantalla es ahora una realidad gracias a Pantallas reactivas. La reactividad permite que los componentes individuales en una pantalla de flujo se comuniquen entre sí, haciendo que los flujos de pantalla sean infinitamente más potentes.

Ejecutar operaciones de datos fuera de pantalla: Los flujos de pantalla ofrecen un enfoque declarativo para obtener datos en la misma pantalla a través de Acciones de pantalla. Las acciones de pantalla pueden permitirle 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. A continuación puede asignar los resultados de estos flujos iniciados automáticamente a la misma pantalla, eliminando la necesidad de que los usuarios naveguen a otra pantalla.

LWC ofrece una gama completa de adaptadores de cable que le permiten acceder a datos de Salesforce para rellenar datos en los componentes de su formulario de forma dinámica, y permite a los desarrolladores actualizar, eliminar y crear registros a través de controladores Apex.

Operaciones de datos fuera de pantalla de componentes web Lightning

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 con funciones de visibilidad de componentes. Con esto, puede mostrar u ocultar campos de forma declarativa basándose en otros valores en el formulario o si el usuario está en un dispositivo móvil o no.

• Con Formularios dinámicos, la visibilidad se puede controlar basándose en valores de campo de registro, registros relacionados a través de campos de búsqueda y factor de forma.
• Con Flujo, puede basar una regla de visibilidad en otras entradas en la pantalla, así como otros recursos rellenados anteriormente en el flujo como fórmulas o valores de otros registros.
  • Reglas basadas en dispositivos: No es 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á en la aplicación móvil Salesforce.
  • Evaluación de otros recursos: Las referencias manuales a variables y fórmulas solo se evalúan en el servidor. Por lo tanto, sea cual sea el valor que tenga ese recurso cuando se represente la pantalla por primera vez, es el valor que tendrá hasta que navegue a otra pantalla. En la navegación, el tiempo de ejecución del flujo envía una solicitud al motor de flujos (el servidor) y obtiene los valores más recientes de las variables y fórmulas manuales. Si espera que su regla de visibilidad se actualice a medida que el usuario pasa por una única pantalla (por ejemplo, desenfoque), asegúrese de hacer referencia únicamente a valores de los otros componentes de la pantalla.
• Con OmniStudio, puede mostrar u ocultar componentes de forma condicional configurando una Propiedad de vista condicional. Sin embargo, no puede agregar más de una propiedad de vista condicional para una entrada.

Estados de entrada condicionales: Si necesita controlar dinámicamente cualquier otra propiedad, como si un campo es obligatorio, si está desactivado o si es de solo lectura, tiene algunas opciones. Como se espera, LWC le proporciona un control reactivo completo sobre su estado de entrada. Con componentes de flujo de pantalla reactivos, puede controlar dinámicamente atributos de componentes como Solo lectura, Desactivado y Obligatorio para componentes estándar que lo admiten, mientras que OmniStudio admite el espectro completo de atributos específicos de componentes. 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, como si un campo es obligatorio o de solo lectura, su mejor apuesta a corto plazo es LWC, donde tiene el control completo. Eso es especialmente cierto si tiene requisitos personalizados sobre cómo gestionar el desenfoque o el onclick.

LWC reactivos en flujos de pantalla: Al crear LWC que pueden reaccionar y cambiar otros componentes en un flujo de pantalla, consulte esta guía Prácticas recomendadas LWC para flujos de pantalla para garantizar que sus componentes se integran bien en el motor de tiempo de ejecución de flujos y funcionan como se espera en el futuro.

Ahora para eventos personalizados. Si algunas de sus entradas o el formulario completo necesitan comunicarse con otra cosa en la página, LWC es su única opción.

• Para comunicarse dentro del mismo árbol DOM, utilice la interfaz CustomEvent.
• Para comunicarse en todo el DOM, utilice Lightning Messaging Service.
• Si Lightning Messaging Service no es compatible con su contenedor de destino, utilice el módulo pub/sub.

• Para obtener más detalles, consulte Comunicarse con eventos y comunicarse a través del DOM en la Guía del desarrollador de componentes web Lightning.
• Para OmniStudio, consulte Comunicarse con OmniScript desde un componente web Lightning.

Para proporcionar la mejor experiencia de usuario, tendrá que asegurarse de que el estilo de su formulario es coherente con el resto de la aplicación o el sitio donde está integrado. Lograr esto puede significar cualquier cosa, desde utilizar plantillas estándar proporcionadas por Salesforce hasta crear CSS personalizado que utiliza completamente cada píxel en el diseño para proporcionar un aspecto más nítido.

• ¿Qué tan sofisticado es su estilo y CSS deseado?
• ¿Necesita un estilo personalizado y perfecto para los píxeles o está de acuerdo con los temas estándar?

FlexCards es el único producto cubierto en esta guía que le permite controlar declarativamente el estilo y el formato de la interfaz de usuario que está creando en la herramienta directamente, ya sean los márgenes y el relleno, la tipografía, los colores, etc.

Tanto Formularios dinámicos como flujos respetan funciones de tema declarativo. Si necesita controlar más allá de lo que admiten Temas de Salesforce, Conjuntos de marca de Experience Builder o Sitios de Experience Cloud LWR, considere una solución programática.

Para equipos que se sienten cómodos trabajando con CSS, tiene un par de opciones:

• Los flujos y los LWC heredan tokens de diseño estándar.
• OmniScripts y FlexCards incluyen compatibilidad para un sistema de diseño personalizable: Newport.
• Con LWC, puede redactar sus propios componentes y controlar completamente el HTML y CSS por ellos.

Siempre que sea posible, recomendamos utilizar temas y sistemas de diseño, de modo que su aspecto se aplique de forma coherente en todo su contenido.

Recordatorio: Puede integrar componentes Lightning en flujos. De modo que si necesita un control perfecto de los píxeles sobre el aspecto de su formulario pero desea utilizar los otros beneficios de los flujos, como el modelo de navegación, puede tener lo mejor de ambos mundos. El mismo principio se aplica a OmniScripts y FlexCards.

La selección de un buen formato es crucial para diseñar formularios simplificados que permiten una entrada de datos rápida y eficiente y aumentan la integridad de los datos. Consulte Salesforce Well-Architected - Formularios para obtener más información sobre este tema.

• ¿Cómo puede utilizar el formato de su formulario para optimizar experiencias de usuario?
• ¿Cómo puede presentar datos existentes a sus usuarios de una forma que les facilite introducir nuevos datos en sus formularios?

Formularios dinámicos admite formatos de dos columnas y se pueden dividir en secciones individuales con campos. Estas secciones se pueden colocar en componentes como fichas y acordeones para crear formatos fáciles de usar y organizados.

Los flujos se pueden representar opcionalmente utilizando el componente Sección. Con las secciones, puede agregar hasta cuatro columnas y tantas secciones como desee en la pantalla de flujo. El componente también tiene capacidad de respuesta al ancho de pantalla, de modo que puede funcionar en pantallas más pequeñas. Por último, le proporciona la capacidad de aplicar visibilidad condicional a toda la sección, facilitando 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 proporcionan una experiencia similar a un acordeón donde los usuarios pueden contraer toda la sección haciendo clic en la etiqueta.

Los OmniScripts cuentan con 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 son aquellas de HTML/CSS. Lightning respeta la configuración de la sección en el formato de página asociado; por ejemplo, si una sección es de dos columnas en el formato de página, es de dos columnas en este componente.

Si su formulario será accesible para usuarios en diferentes regiones o que hablan diferentes idiomas, tendrá que asegurarse de que la herramienta que utilizará para crearlo cumplirá sus requisitos de localización. Consulte Salesforce Well-Architected - Localization para obtener directrices y recomendaciones adicionales. En el caso de formularios específicamente, los requisitos de localización normalmente implican traducir elementos de texto a otros idiomas.

• ¿Se utilizará su formulario en más de un país o región?
• ¿Necesita el texto de su formulario traducirse a otros idiomas?

Si localizó sus campos personalizados, esas etiquetas traducidas se respetan en Formularios dinámicos. Formularios dinámicos también respeta las etiquetas personalizadas que asignó a etiquetas de componentes y atributos en el Generador de aplicaciones Lightning.

Con el poder de Sistema de traducción, Flow admite la traducción de etiquetas de cara al usuario para todos los componentes de pantalla estándar y personalizados. Puede traducir la etiqueta, el texto de ayuda y el mensaje de error de 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, Grupo de casillas de verificación, Contraseña, Fecha y Fecha/hora.

No hay compatibilidad de traducción integrada para acciones listas para su uso, como Enviar correo electrónico o Publicar en Chatter. Sin embargo, hay una solución! Si define las etiquetas traducidas con una etiqueta personalizada, puede hacer referencia a esa etiqueta personalizada en la acción o el componente cuando la configura en Flow Builder. Cree una fórmula de flujo que haga referencia a la etiqueta personalizada y haga referencia a esa fórmula en los lugares apropiados de su flujo.

Los OmniScripts utilizan etiquetas personalizadas para traducciones. Consulte este documento de ayuda para preparar sus OmniScripts en varios idiomas.

Ahora para LWC. Algunos componentes base heredan automáticamente traducciones de los campos, el texto de ayuda y los mensajes de validación del objeto asociado si se configuraron en Sistema de traducción (por ejemplo: Lightning).

Si necesita introducir etiquetas traducibles novedosas en su código, las etiquetas personalizadas siguen siendo el héroe desconocido. Declare la etiqueta personalizada que necesita y luego impórtela en su componente desde el módulo con ámbito @salesforce/label.

Existen varias herramientas de automatización de pruebas de extremo a extremo disponibles (por ejemplo, Selenium), que le permitirán simular cómo interactúa el usuario con su formulario. Puede redactar estas pruebas para cualquier interfaz de usuario estándar o personalizada, incluyendo páginas Lightning y flujos de pantalla. Sin embargo, es importante tener en cuenta que estos tipos de pruebas no pueden verificar los resultados de cada método que se está realizando. Asegúrese de tener esto en cuenta cuando piense en sus requisitos para la automatización de pruebas de la interfaz de usuario.

• ¿Necesita pruebas automatizadas para su formulario?
• ¿Qué tipos de pruebas necesita realizar?
• ¿Qué nivel de granularidad necesita en sus automatizaciones de prueba?

Considere sus requisitos para la automatización de pruebas de la interfaz de usuario.

Las pruebas de unidad permiten una automatización y validación más granular que funciona con herramientas y sistemas de CI/CD estándar del sector, que pueden probar la lógica comercial de componentes, su controlador JavaScript y sus salidas. Pasando exclusivamente con código bajo no podrá realizar pruebas de autoría, pero Salesforce prueba rigurosamente nuestras ofertas integrales.

Si los métodos de su componente son lo suficientemente complejos como para que desee que se prueben individualmente, coloque los métodos en archivos JavaScript exclusivos. De ese modo puede importarlos en un LWC y en una prueba de Jest con algo como import { sort } from 'c/utils';.

Consulte Automatización de pruebas de la interfaz de usuario para obtener una comparación de las diversas opciones que tiene para crear automatización integral en Salesforce. Se incluyen consideraciones sobre cuándo utilizar una solución sin código desde un ISV, Build Your Own solución de automatización de pruebas personalizada o utilizar un marco de trabajo de prueba de código abierto como Selenium WebDriver o WebdriverIO. Estas soluciones son válidas para cualquier interacción de la interfaz de usuario en Salesforce, ya sea un Formulario dinámico en una página Lightning, un flujo de pantalla en una barra de utilidades o un LWC en un flujo en una acción rápida.

Después de implementar su formulario en un entorno de producción, querrá asegurarse de que se está utilizando de forma efectiva. Dependiendo de su caso de uso, esto puede significar cualquier cosa, desde simplemente realizar un seguimiento del número de veces que se ha rellenado hasta la cantidad de tiempo que emplean los usuarios en rellenarlo antes de enviar su información. Asegúrese de identificar los indicadores clave de rendimiento que desea supervisar antes de seleccionar una herramienta.

• ¿Necesita realizar un seguimiento del uso de su formulario?
• ¿Qué KPI determinarán si su formulario se está utilizando de forma efectiva?

Si necesita realizar un seguimiento del uso general y la adopción de su formulario, comience con las herramientas de código bajo. Tanto Formularios dinámicos como Flujos de pantalla son rastreables utilizando tipos de informes personalizados listos para su uso, aunque obtendrá más granularidad de los informes de seguimiento de Flujo de pantalla. Si necesita realizar un seguimiento del uso de un LWC, la disponibilidad de uso inmediato depende de dónde está utilizando ese LWC. Si está en una página Lightning, lo que esté disponible para realizar un seguimiento del uso de la página Lightning se aplica a su LWC. La misma historia se aplica a los LWC incrustados en flujos.

Los Formularios dinámicos en sí no son rastreables de forma inmediata, aunque puede realizar un seguimiento del uso de la página Lightning principal a través de objetos de uso Lightning. Para realizar un seguimiento de las páginas Lightning estándar, utilice el tipo de informe personalizado Usuarios con uso Lightning por mediciones de página. Para lo mismo en páginas Lightning personalizadas, utilice el tipo de informe personalizado Usuarios con Lightning Usage by FlexiPage Metrics.

Para realizar un seguimiento de la adopción de su formulario específico (no solo la página en la que reside), Flow le tiene cubierto. Utilice el “Informe de flujo de ejemplo: Flujos de pantalla” para responder a preguntas como:

• ¿Cuál es el índice de cumplimentación de este formulario? ¿Está siendo bien adoptado?
• ¿Cuánto tardan los usuarios en rellenar este formulario?
• ¿En qué pantalla emplean los usuarios más tiempo?
• ¿Con qué frecuencia navegan los usuarios hacia atrás?
• ¿Con qué frecuencia se producen errores?

Si el informe estándar no cumple sus necesidades, duplique el informe para realizar sus propios cambios o Build Your Own desde cero utilizando el tipo de informe Flujos de pantalla.

Si está utilizando el tiempo de ejecución de OmniScript basado en paquetes, puede utilizar OmniStudio para Vlocity Tracking Service. Este servicio realiza un seguimiento de cualquier tipo de evento. Por ejemplo, puede realizar un seguimiento del tiempo que tarda en completar los pasos en un OmniScript para identificar mejoras de procesos. Está en la hoja de ruta del equipo de OmniStudio admitir este servicio en OmniStudio estándar.

Para realizar un seguimiento de lo mismo para un LWC que no está integrado en un flujo de pantalla, OmniScript o una página Lightning, no hay ninguna opción lista para su uso. Puede crear una solución personalizada utilizando Apex.

Cuando necesite implementar su solución en entornos superiores para realizar pruebas o implementar en producción, es posible que esté acostumbrado a utilizar conjuntos de cambios o DevOps Center para hacerlo. Formularios dinámicos, Flujos y LWC son completamente compatibles en esas opciones de implementación. OmniStudio requiere una herramienta separada: IDX Workbench.

• ¿Cómo piensa implementar su formulario?
• ¿Se distribuirá su formulario a más de una organización de Salesforce?

Si es un ISV o socio que planea empaquetar su solución para su distribución en AppExchange, recomendamos mirar primero Formularios dinámicos, Flujos y LWC. OmniStudio no admite el empaquetado.

Esta guía se ha centrado en ayudarle a comprender qué funcionalidad y nivel de personalización es posible con Formularios dinámicos, flujos de pantalla, OmniStudio y LWC. En un nivel superior:

• LWC es la opción más personalizable y robusta para crear un formulario, pero tiene el menor número de barandillas en su lugar. Depende de usted crear un componente de una forma que garantice la seguridad y la escalabilidad.
• Formularios dinámicos es el menos flexible, pero hay muchas menos oportunidades de pasos en falso.
• Flow y OmniStudio se encuentran en algún punto del medio, más potentes que Formularios dinámicos pero no del todo al nivel de LWC. Del mismo modo, tienen menos barandillas que Formularios dinámicos pero son más difíciles de romper que el código personalizado.

Si múltiples herramientas se ajustan a la ley, la decisión se reduce a qué herramienta es la correcta para su equipo. Otras guías de decisiones de arquitectos presentan aspectos adicionales a tener en cuenta al tomar esa decisión.

No entraremos en los detalles de cada uno de esos aspectos aquí, pero lo que haremos será interpretarlos para las herramientas específicas que este documento está evaluando.

Habilidades especializadas: ¿Cuánta experiencia tiene su equipo en las herramientas que está comparando? ¿Cuántos fabricantes están bien familiarizados con LWC o JavaScript? ¿Qué hay de los creadores que son expertos en Flow Builder o que han expresado interés en hundir los dedos de sus pies? En términos generales, las habilidades Formularios dinámicos y Flujo son más alcanzables para una población más amplia de personas que crean formularios. Formularios dinámicos es la herramienta de creación de formularios más declarativa y siempre será más fácil aprender que Flujo. Dicho esto, el equipo de Flow se compromete a reducir ese listón lo más posible. En términos de complejidad, OmniStudio se encuentra en algún punto entre Flow y LWC y ofrece superpotencias de creación de formas significativas.

Delegación de entrega: Solo porque algunos de sus requisitos requieren LWC no significa que toda su solución tenga que crearse con LWC. Considere cómo puede crear su solución de forma modular, de modo que las piezas que requieren LWC se codifiquen y las piezas que no se crean en una solución de código bajo. Al hacerlo se maximiza la eficiencia de un equipo diverso y se garantiza que cada individuo esté resolviendo problemas apropiados para su especialización.

Ahora hablemos de Flujo y LWC. Con Componentes de pantalla reactivos, los componentes de flujo de pantalla ahora pueden hablar entre sí en la misma pantalla desbloqueando un cofre de herramientas completamente nuevo para arquitectos, administradores y desarrolladores. Los desarrolladores ahora pueden crear componentes modulares específicos que se pueden reutilizar en toda la organización, potenciando la productividad para todos en el equipo. Los desarrolladores pueden centrarse en resolver nuevos retos y ahorrar tiempo utilizando una mezcla de componentes de flujo estándar y personalizados para lograr el dinamismo de la forma. Con componentes reactivos en Flujo, nunca ha habido un momento más apropiado para mezclar Flujo y LWC al crear sus formularios.

Mantenibilidad y propiedad a largo plazo: Si tiene un formulario de múltiples pasos, es una buena idea empezar con Flujo o una mezcla de Flujo y LWC. Si tiene un equipo de código bajo manteniendo la solución, piense en cómo puede hacer que la solución sea lo más configurable y ampliable posible para esa audiencia. Independientemente de la herramienta que elija, organice su solución en unidades componibles para mejorar la capacidad de mantenimiento y la estabilidad.

En adelante, la forma recomendada de configurar páginas de detalles de registro es Formularios dinámicos en el Generador de aplicaciones Lightning utilizando páginas Lightning. Ha pasado mucho tiempo desde que tenemos formatos de página mejorados, y esa tendencia continuará. Este es el motivo:

• Formularios dinámicos son más flexibles: puede colocar campos y secciones donde desee directamente en el Generador de aplicaciones Lightning, donde puede aprovechar secciones, fichas y acordeones. Del mismo modo que puede hacer con componentes en la página Lightning, puede controlar la visibilidad de sus campos y secciones sin definir múltiples formatos de página o tipos de registro.
• Con los componentes Acordeón y Ficha, puede restringir la cantidad de campos que se muestran inicialmente. ¿Adivina lo que eso significa? Tiempos de carga de página más rápidos.
• La gestión de formatos es más sencilla con páginas Lightning, ya que puede gestionar todo acerca de sus páginas desde el Generador de aplicaciones Lightning, ya sean los contenidos de la página o los usuarios que tienen acceso a la página. Ya no es necesario realizar actualizaciones en su formato de página para realizar un cambio en su página Lightning. Sin mencionar que con el poder de las reglas de visibilidad, ya no tiene que crear múltiples páginas (o formatos de página) para controlar quién ve qué campos cuándo. Y eso también significa que solo necesita asignar a los usuarios una página Lightning en vez de asignar una página Lightning y un formato de página.

Recomendamos utilizar Formularios dinámicos siempre que sea posible y volver a los formatos de página solo cuando sea necesario. Como siempre, damos la bienvenida a comentarios en el Intercambio de ideas sobre las mejoras que serían más impactantes para su organización.

Cualquier consideración de rendimiento relacionada con Formularios dinámicos, flujos de pantalla, OmniStudio y LWC se centra en qué marco se encuentran esas tecnologías en sí. Los que están basados en LWC (además, por supuesto, de un LWC) van a superar a los que están basados en Aura. El marco de trabajo LWC ofrece un mejor rendimiento porque las funciones principales se implementan de forma nativa en motores web en vez de en JavaScript a través de abstracciones de marco de trabajo. Si no está familiarizado, dé una lectura a esta publicación.

En 2019, realizamos un estudio de caso comparando el rendimiento de la misma función en Aura frente a en LWC. Como resultado de la conversión de DreamHouse de Aura a LWC, la experiencia de desarrollo no solo estaba mucho más alineada con los estándares y patrones de desarrollo front-end web actuales, sino que las ganancias de rendimiento fueron significativas. Las mediciones de laboratorio mostraron ganancias en el rango del 2,4 por ciento al 24,7 para caché en frío y ganancias en el rango del 31,83 por ciento al 63,32 por ciento para caché caliente en las mismas dos páginas.

Ahora, ¿qué marco de trabajo están utilizando nuestras tecnologías de formularios? En otras palabras, ¿qué tecnologías de forma se benefician de este rendimiento superior?

• Formularios dinámicos, que está integrado en los metadatos de páginas Lightning, está construido sobre una base que utiliza la pila LWC, lo que nos permitirá implementar algunas funciones solicitadas desde hace tiempo. Como ventaja de rendimiento, Formularios dinámicos utiliza la representación progresiva, lo que da como resultado un tiempo de carga de página mejorado para páginas que tienen un gran número de campos.
• Los flujos de pantalla se crean en LWC con la mayoría de los componentes de uso inmediato individuales convertidos ahora a LWC con la excepción de dos componentes de uso inmediato: Imagen y carga de archivo. Aunque el equipo de Flow convirtió el cliente de tiempo de ejecución de flujo a LWC así como la mayoría de sus componentes, los clientes aún necesitan convertir sus componentes de pantalla Aura a LWC. No solo eso, sino que Salesforce solo admite componentes LWC en el nuevo marco de componentes reactivos en flujos de pantalla. Existe un excelente módulo Trailhead que explica cómo hacerlo: Componentes web Lightning para desarrolladores Aura. Huelga decir que: Si está pensando en crear un componente personalizado para un flujo de pantalla o cualquier otro contenedor, vaya siempre a LWC.
• Existen algunas versiones de OmniStudio disponibles. Si es un cliente de larga trayectoria, es posible que esté utilizando Angular. Animamos a todos los nuevos clientes a comenzar con FlexCards y OmniScripts basados en LWC, y a que los clientes existentes migren de Angular.
• LWC se basa en ... LWC por supuesto. Esto es un regalo. 🤓

Como arquitecto, es importante tener un conocimiento sólido de todas las opciones disponibles y cómo puede aplicarlas en su caso de uso específico. Para la creación de formularios en Salesforce, las opciones van desde código bajo (utilizando Formularios dinámicos en el Generador de aplicaciones Lightning, Flujos de pantalla en Flow Builder y OmniScripts en OmniStudio) a código profesional (utilizando el marco de trabajo LWC), con una combinación de flujos de pantalla u OmniScripts y LWC en el medio. Tenga en cuenta esta guía y utilícela como referencia cuando esté planificando crear o rediseñar formularios en Salesforce. Si está buscando directrices sobre cómo diseñar formularios simplificados y útiles, consulte Salesforce Well-Architected: Implicante.

Ayúdenos a asegurarnos de publicar lo que es más relevante para usted: realice nuestra encuesta para proporcionar comentarios sobre este contenido y díganos qué le gustaría ver a continuación.