Construcción de formularios

Existen múltiples opciones para crear 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 el Generador de aplicaciones Lightning y flujos de pantalla en Flow Builder se pueden utilizar para soluciones de código bajo. Por otro lado, el marco de componentes web Lightning (LWC) se utiliza para soluciones de código profesional. Dentro del continuo, las herramientas se pueden combinar de varias formas utilizando flujos de pantalla ampliados por LWC y formularios de cara al cliente creados utilizando OmniStudio.

Esta guía presenta un marco de decisión 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.

• Cuando cree/modifique/vea formatos para páginas Lightning, utilice Formularios dinámicos. En adelante, recomendamos utilizar Formularios dinámicos en el Generador de aplicaciones Lightning 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 navegación lineal para orquestar múltiples formas. Puede utilizar LWC para crear su propio marco de trabajo para navegar entre formularios, pero recomendamos dejar 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 ampliar más allá de la creación o modificación de un único registro. En este caso, 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 correos electrónicos o la distribución 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 que la visibilidad de la interfaz de usuario, utilice LWC u OmniScript. Para requisitos que se pueden cumplir utilizando formatos basados en temas y columnas, 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 en 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 comercial 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 juntas).

Las siguientes herramientas se utilizan habitualmente para implementar y ampliar experiencias de formulario.

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.

Hay una serie de 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 orientación de alto nivel.

Nota: En tablas de comparación de decisiones posteriores, hay un puñado de valores asociados con cualquier par de herramientas-funciones:

• 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.

Utilice estos escenarios para comparar opciones de herramientas basándose en ámbito, UX y necesidades operativas.

Si puede obtener todas sus entradas de usuario desde un formulario de pantalla única, comience con Formularios dinámicos. Tenga en cuenta que Formularios dinámicos en páginas de registro pueden utilizar la función Ruta para dar cobertura a procesos comerciales por etapas.

• ¿Necesita una única pantalla o el usuario tendrá que navegar entre múltiples pantallas para completar una tarea?

• ¿Desea que sus usuarios vean una descripción visual de lo avanzado que se encuentran en el proceso al rellenar su formulario? ¿Se pedirá a sus usuarios que rellenen la información de 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, elegir 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 Flujo de pantalla y OmniScript proporciona un UX no deseado, 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.

Si elige Flujo u OmniStudio, es posible que también tenga que crear un LWC para alcanzar el UX correcto. Si ya está creando un LWC para diseñar su formulario correctamente, considere si es necesario integrar ese componente en un flujo.

Navegación 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. Los flujos y OmniStudio cuentan con 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 dentro del 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.

Si 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.

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 actualmente 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.

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

Como requiere contexto de registro, la función Formularios dinámicos solo es compatible 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 registro, 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 se admiten 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 crear componentes que se pueden asociar con objetivos 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.

Los componentes LWC también pueden iniciar flujos con el componente Lightning Flow.

OmniStudio destaca en la exposición de contenido en 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.

Formularios dinámicos son perfectos si necesita utilizar los valores de su formulario para crear o actualizar un registro. Tendrá que aprovechar Flow, OmniStudio o LWC para funciones fuera de ese ámbito, incluyendo la creación de capas 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 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?

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

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, sobresale en el aplanamiento y 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 dentro de la solución que elija (por ejemplo, si necesita filtrar registros desde un LWC, puede utilizar el adaptador de cable 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. El flujo facilita la combinación de entradas desde múltiples formularios (pantallas de flujo) y su uso posterior 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 de un lado a otro entre pantallas para cambiar sus respuestas).

Las transacciones y los límites reguladores 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 única transacción en vez de realizarlas entre 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, ¿deben revertirse los dos primeros registros? Si cada una de sus acciones es independiente 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 única 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 los 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 del pedido 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 (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 neta nueva.

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 dentro de 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 conexión de transacción y base de datos. A continuación, la API llama al motor de flujos para invocar la solicitud.

4. El motor de flujo toma el relevo y sigue la ruta apropiada en la definición de 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 en la base de datos (según 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 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, se confirma cualquier acción pendiente o DML, se cierra la transacción anterior y comienza una nueva transacción. Recuerde que los elementos de diseño específicos (qué operaciones agrupa en una transacción concreta) dependen de usted.

Estos son algunos ejemplos:

• 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 Registros de reversión para permitirle revertir una transacción completa si una única operación falla en una serie de operaciones de base de datos. 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 la tercera no. 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 y Flujo masivo en transacciones.

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 de registro 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 dentro de 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.

Flow, OmniStudio y LWC admiten eventos de plataforma (para arquitectura dirigida por eventos) e integraciones de API. Además del código Apex personalizado, Flow y OmniStudio tienen mecanismos de asistencia declarativa que también pueden integrarse con las API.

Si necesita conectarse a una API de MuleSoft o bot RPA, utilice Servicios de MuleSoft, ya que esto genera un Servicio externo.

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

Para todas las demás instancias, utilice la función Llamada HTTP (con tecnología de Servicios externos) en Flujo o la Acción HTTP en OmniStudio.

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.

Tenga en cuenta que la limitación principal 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, 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. 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. Dado que la llamada LDS está aislada dentro de su propia transacción (separada de la llamada Apex), esto le protege de la incoherencia de datos resultante.

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í mismo y como un subflujo.

OmniStudio está construido inherentemente para 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 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 se puedan componer, también obtiene beneficios de adaptabilidad y estabilidad.

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 el 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 de Apex.

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

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 permiten establecer la obligación y el estado de solo lectura a nivel de página. Tenga en cuenta que no puede sustituir la configuración a nivel del sistema.

El 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 dentro de reglas de validación de entrada). Como nivel de seguridad adicional, 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, se bloquea la navegación y se muestra el error apropiado.

El servidor valida las entradas comprobando:

• La configuración de requisitos de la entrada o si el valor introducido 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 dentro del 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 en combinación con Vistas condicionales y el componente Mensajería.

Para 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 la página). Para sus componentes personalizados, puede Build Your Own mecanismos de validación.

Recuerde que los campos que requieren que los usuarios introduzcan datos deben aparecer al principio de sus formularios. Valide entradas de usuario en el lado del cliente antes de enviar formularios (cuando sea posible).

Los formularios estáticos están desfasados. Hoy en día, el enfoque ha cambiado a la actualización dinámica de formularios con las propiedades y 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.

• ¿Qué tipos de interacciones o condiciones deben desencadenar respuestas dinámicas en su formulario?

• ¿Necesita ejecutar operaciones fuera de 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?

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 dentro de 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 cable 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.

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 manuales a variables y fórmulas 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 los valores de fórmula y variables manuales 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 onblur u 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 Prácticas recomendadas LWC para flujos 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.

Para eventos personalizados, si algunas de sus entradas (o el formulario completo) necesitan comunicarse con otro elemento de la página, LWC es su única opción.

• Para comunicarse dentro del mismo árbol DOM, utilice la interfaz CustomEvent.

• Para comunicarse en el DOM, utilice el Servicio Lightning Messaging.

• Si Lightning Messaging Service no es compatible con su contenedor de destino, utilice el módulo pub/sub.

• Para obtener información más detallada, 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, 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.

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 generadores 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, resaltar una pantalla de confirmación o enfatizar 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 Tema de sitio LWR

2. Sustituciones de estilo de flujo: Ajustes de componente o pantalla dirigidos

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 permanezca coherente, ampliable y fácil de mantener a lo largo del tiempo.

• ¿Qué tan sofisticado es su estilo y CSS deseado?

• ¿Necesita un estilo personalizado y perfecto para los píxeles o temas estándar?

FlexCards es el único producto en esta guía que le permite controlar declarativamente el estilo y el formato de la interfaz de usuario que está creando dentro de la herramienta (por ejemplo, márgenes y relleno, tipografía, colores, etc.).

Los flujos y formularios dinámicos respetan funciones de tema declarativo. Si necesita control adicional (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.

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.

• Los OmniScripts y FlexCards incluyen compatibilidad con sistemas de diseño personalizable a través de Newport.

• 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.

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.

• ¿Cómo puede estructurar formatos de formulario para optimizar experiencias de usuario?

• ¿Cómo puede presentar datos existentes a los usuarios de una forma que les facilite introducir nuevos datos en sus formularios?

Formularios dinámicos admite formatos de dos columnas que se pueden dividir en secciones individuales dentro de campos. Estas secciones se pueden colocar dentro de 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 al ancho de pantalla, por lo 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 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 proceden de HTML y CSS. El componente de formato Lightning 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).

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.

• ¿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 localiza campos personalizados, Formularios dinámicos respeta las etiquetas traducidas. Formularios dinámicos también respeta cualquier etiqueta personalizada asignada a etiquetas y atributos de componentes en el Generador de aplicaciones Lightning.

Flow admite la traducción de etiquetas de cara al usuario para todos los componentes de pantalla estándar y personalizados a través del 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 correo electrónico o Publicar en Chatter), pero hay una solución. Si utiliza una etiqueta personalizada 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 dentro de su flujo.

Los OmniScripts utilizan etiquetas personalizadas para traducciones. Para obtener más información, consulte este documento de ayuda para asegurarse de que sus OmniScripts están listos para múltiples 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.

Utilice esta sección para evaluar la seguridad, la calidad y las restricciones operativas antes de la implementación.

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 ejecuta 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 desee tomar medidas adicionales para eliminar direcciones URL o código potencialmente malintencionado de campos de texto enriquecido, evitar que ciertos usuarios accedan al formulario o establecer limitaciones en los tipos de ubicaciones donde los administradores pueden incrustar el formulario en el futuro.

Asegúrese de documentar sus requisitos de seguridad minuciosamente antes de elegir una herramienta. Para obtener directrices adicionales sobre este tipo de documentación, consulte la Plantilla de política de seguridad bien arquitectónica de Salesforce.

• ¿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 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 en particular 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 que se ejecute 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 tiene influencia sobre quién considera Salesforce que es 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 el 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 compartició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 comercial 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.

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 introducirse en el formulario.

• 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.

• Cuando consulte 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 se deben ejecutar dentro del 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, desinfecte las entradas de usuario para eliminar HTML utilizando un Flujo de actualización de campo rápida o Desencadenador Apex.

• 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 dentro de 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 con colaboración o sin colaboración.

Si necesita controlar quién puede acceder a un formulario, revise el contenedor donde está integrado 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 a perfiles o conjuntos de permisos concretos (similar a la clase Apex o a las 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 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.

• 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 equilibrios 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 comercial 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.

Los LWC solo están disponibles en una ubicación determinada después de que se hayan agregado como un destino válido (por ejemplo, puede hacer que un componente esté disponible en páginas de registro y no esté disponible 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. Flow Builder admite múltiples tipos de flujos que tienen pantallas. El tipo más destacado es Flujo de pantalla, pero hay algunos otros tipos especializados restringidos a ubicaciones específicas (por ejemplo, la aplicación móvil Field Service solo admite Flujos móviles Field Service). 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.

En Salesforce, existen varias herramientas de automatización de pruebas integrales (por ejemplo, consulte UTAM de Salesforce) 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.

• ¿Necesita pruebas automatizadas para sus formularios?

• ¿Qué tipos de pruebas tiene intención de realizar?

• ¿Qué nivel de granularidad es necesario para automatizaciones de pruebas?

Considerar requisitos de automatización de pruebas de la interfaz de usuario

Las pruebas de unidad proporcionan automatización granular y validación que se alinea con herramientas y sistemas de CI/CD estándar del sector, que prueban la lógica comercial, los controles 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 integrales.

Si los métodos de su componente son complejos, puede enviarlos por texto de forma individual 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).

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 indicadores clave de rendimiento rastreables antes de seleccionar una herramienta.

• ¿Necesita realizar un seguimiento del uso de formularios?

• ¿Qué KPI pueden determinar si el formulario se está utilizando de forma efectiva?

Si necesita realizar un seguimiento del uso y la adopción general de formularios, utilice herramientas de código bajo. Los flujos de pantalla y formularios dinámicos son rastreables a través de informes personalizados listos para su uso. Sin embargo, los informes 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 son detectables de forma inmediata; sin embargo, 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 páginas Lightning estándar, utilice el informe personalizado Usuarios con Lightning Usage by Page Metrics. Para páginas Lightning personalizadas, utilice el informe 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 informe de flujo de ejemplo: Flujos de pantalla para responder a estos tipos de preguntas:

• ¿Cuál es el índice de cumplimentació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 informe estándar no cumple sus necesidades, puede duplicarlo y realizar cambios o Build Your Own Report desde cero utilizando el informe 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. 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 de 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.

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.

• ¿Cómo piensa implementar el formulario?

• ¿Es necesario distribuir el formulario a más de una organización de Salesforce?

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. Tenga en cuenta que OmniStudio no admite el empaquetado.

Esta guía pretende mostrarle qué niveles de personalización y funcionalidad están disponibles a través de Formularios dinámicos, flujos de pantalla, OmniStudio y LWC. 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 robusta y personalizable, pero tiene el menor número de barandillas en su lugar. Por eso es crucial crear sus componentes teniendo en cuenta la seguridad y la escalabilidad.

• Formularios dinámicos es la opción menos flexible, pero tiene muchas menos oportunidades de pasos en falso.

• Flow y OmniStudio caen ligeramente en el medio. Son más potentes que Formularios dinámicos, pero no están a la altura del nivel de 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 vea 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 de arquitecto.

• Cuando compara herramientas, es importante evaluar la experiencia que tiene su equipo con respecto a cada herramienta.
• ¿Cuántos de sus desarrolladores están bien versados en LWC o JavaScript?
• ¿Hay algún desarrollador en su equipo que sea experto en Flow Builder o que haya 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 crearse 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 se pueden sincronizar 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 forma, 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, independientemente de la herramienta que seleccione.

Las consideraciones de rendimiento 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 que se implementan 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 rendimiento mejorados.

Por lo tanto, ¿cómo aprovechamos estos beneficios de rendimiento para nuestras tecnologías de formularios en Salesforce? Echemos un vistazo con más detalle.

• Formularios dinámicos (integrados en metadatos de páginas Lightning) está construido sobre una base de pila de LWC, que nos permite implementar varias funciones muy esperadas. Como ventaja de rendimiento adicional, Formularios dinámicos utiliza la representación progresiva, que mejora el tiempo de carga para páginas que tienen un gran número de campos.

• Los flujos de pantalla se basan en LWC. La mayoría de los componentes de uso inmediato individuales se han convertido ahora a LWC con la excepción de los componentes Carga de archivo 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. Tenga en cuenta que Salesforce solo admite componentes LWC dentro del marco de trabajo Componente reactivo en flujos de pantalla. Para obtener más información, consulte el módulo Trailhead Componentes web Lightning para desarrollador Aura. Si está contemplando 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 trayectoria, 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.