# architect Guías de decisiones (decision-guides) - Full Documentation # Aprovisionamiento de Data 360 Salesforce Data 360 es una plataforma de datos creada sobre [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) que unifica datos externos y de Salesforce en una visión clara, completa y de confianza de 360 grados de cada cliente o cuenta. Las compañías a menudo operan múltiples organizaciones de Salesforce debido a fusiones y adquisiciones, operaciones regionales, separación funcional o por motivos históricos. Los arquitectos tienen que tomar varias decisiones acerca de Data 360, todas las cuales afectan a la gobernanza, el cumplimiento, el costo, la latencia y la capacidad de la organización para ampliar la IA y las funciones de plataforma entre organizaciones. ## Descripción general de guía Esta guía proporciona un marco para tomar decisiones de aprovisionamiento con Data 360\. Estas decisiones incluyen: - Selección de una única organización de inicio frente a una configuración de múltiples organizaciones - Aprovisionamiento de múltiples instancias independientes de Data 360 - Utilizar Data Cloud One para unificar organizaciones bajo una única instancia - Colaborar entre instancias de Data 360 independientes que utilizan la colaboración de datos entre organizaciones de Data 360 Data 360 se aprovisiona automáticamente en cualquier organización de producción que recibe una licencia de Data 360. Data Cloud One es la arquitectura de conectividad de múltiples organizaciones de Salesforce que permite a una única organización de inicio alojar la instancia de Data 360, mientras que otras organizaciones de Salesforce se conectan como organizaciones complementarias. La elección de qué organización posee la licencia Data 360 y, por lo tanto, se convierte en una organización de inicio de Data 360, es una decisión arquitectónica crítica con consecuencias a largo plazo. El modo de aprovisionar Salesforce Data 360 es una decisión arquitectónica fundamental. Determina cómo la compañía unifica datos de clientes, aplica la gobernanza y activa funciones de plataforma críticas, especialmente IA, Agentforce y análisis en toda la organización. Anclar un clúster de organizaciones a un único Data 360 proporciona un modelo de datos unificado, una gobernanza centralizada y permite la preparación de IA de toda la compañía. Las organizaciones complementarias pueden acceder a funciones y metadatos compartidos como si los datos fueran locales. Por el contrario, múltiples instancias independientes de Data 360 son apropiadas cuando los requisitos de regulación, cumplimiento o autonomía impiden la centralización. La colaboración de datos entre organizaciones de Data 360 permite la colaboración selectiva sin copia entre estas instancias. Esta decisión influye en quién controla la gobernanza de los datos, dónde residen los datos, cómo se activan las funciones de la plataforma y cuán suavemente se pueden ampliar futuras integraciones e iniciativas de IA. Incluso para organizaciones que no tienen Data 360 en estos momentos, puede ser importante preparar sus arquitecturas para el futuro desarrollando una estrategia para agregar acceso a Data 360 en adelante. Cada vez más, las funciones de Salesforce entre Sales, Service, Marketing, Commerce, Industries y Agentforce están construidas sobre Data 360\. Las organizaciones que desean utilizar estas funciones de plataforma deben aprovisionar sus propios Data 360 o conectarse a un Data 360 compartido como organizaciones complementarias. Esta guía ayuda a los arquitectos a diseñar una estrategia de aprovisionamiento que equilibra la sencillez, la coherencia de toda la compañía, el cumplimiento y la capacidad de ampliación, garantizando que la organización puede aprovechar con confianza Data 360 para Customer 360, la IA y la innovación entre plataformas. Utilice esta guía para determinar qué organizaciones requieren Data 360 y si utilizar Data Cloud One o la colaboración de datos entre organizaciones de Data 360. Esta estrategia establece una base firme para un futuro centrado en Data 360. ## Productos en ámbito
Logotipo de Salesforce Platform Salesforce Data 360 es la plataforma de datos hiperescala en tiempo real de Salesforce que armoniza y unifica datos desde cualquier origen (CRM, web, móvil o lagos de datos externos) en un único perfil de cliente con capacidad de acción. Como componente crítico de la plataforma Customer 360, potencia la IA, los análisis y las experiencias personalizadas en ventas, servicio y marketing.
## Comida para llevar - **Cada organización debe planificar el acceso a una instancia de Data 360.** Cada organización debe alojar una organización de inicio de Data 360 o ser una organización complementaria conectada a través de Data Cloud One. - **Piense en toda la compañía, no organización por organización.** Evite decisiones unilaterales de la línea de negocio tomadas de forma aislada. Idealmente, una arquitectura de compañía o un consejo de gobernanza de datos debe decidir colectivamente sobre la estrategia de aprovisionamiento. Anticipe siempre necesidades futuras de IA y análisis, que dependen de conjuntos de datos amplios y unificados. - **Planifique la gobernanza y la propiedad de forma temprana.** Decida si gestionar Data 360 de forma centralizada (modelo Centro de excelencia) o delegada a líneas de negocio. Defina funciones para administradores, equipos de seguridad y prospectos de cumplimiento. Evite la ambigüedad, ya que la propiedad poco clara puede ser problemática. - **Recuerde que el aprovisionamiento está vinculado a las licencias.** La organización donde se adquiere la licencia Data 360 determina dónde se aprovisiona Data 360 y la ubicación de esa organización determina la región. - **Comprenda las consideraciones de asistencia de origen de datos.** Preste mucha atención a qué regiones son compatibles con varias nubes públicas y orígenes de datos de copia cero. Del mismo modo, determine si se requiere Conexión privada para su postura de seguridad para conectar con esos orígenes de datos y si se admiten conexiones en región o entre regiones. - **Aprovisionamiento basado en si tiene una única organización o múltiples organizaciones.** Para clientes de una sola organización, aprovisione Data 360 en su organización de producción existente para el tiempo de valor más rápido. Para clientes de múltiples organizaciones, minimice la complejidad creando el menor número posible de instancias de Data 360, idealmente utilizando la configuración de Data Cloud One. - **Utilice** **múltiples instancias de Data 360 solo cuando sea necesario.** Solo se deben utilizar múltiples instancias cuando lo requiera el cumplimiento, la residencia o la autonomía organizativa. En estos casos, utilice la [colaboración de datos](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5) entre organizaciones de Data 360 para activar la colaboración segura. - **Configure la colaboración de datos entre organizaciones de Data 360 para la colaboración, no para oportunidades en curso de ETL personalizadas.** Comparta objetos específicos (DMO, perspectivas calculadas, segmentos) a través de colaboraciones de datos. Recuerde que las etiquetas no se comparten y que el consumo se factura a la organización de origen. - **Evite accesos directos a corto plazo.** No ponga en marcha múltiples organizaciones de Data 360 para probar conceptos (POC) sin un plan a largo plazo. Alinee pilotos e implementaciones tempranas con su estrategia de aprovisionamiento de toda la compañía. ## Puntos de decisión Evalúe cada opción de aprovisionamiento (elección entre Data Cloud One, colaboración de datos entre organizaciones de Data 360 o designación de organización de inicio) con estas consideraciones transversales.
Consideración Por qué importa Escenarios de ejemplo
Residencia y cumplimiento de datos Determina dónde se almacenan y procesan los datos. Las reglas reguladoras pueden requerir regiones específicas o múltiples instancias. Un banco global aprovisiona un arrendatario de Data 360 en una organización de Salesforce geolocalizada en Frankfurt para el cumplimiento del RGPD. Aprovisionan otro arrendatario en una organización en Virginia para su división de EE.UU.
Gobernanza y seguridad Identifique un administrador y la propiedad de Data 360, incluyendo estrategias de delegación y gestión de políticas. Una multinacional con una sólida TI central crea una organización de inicio dedicada gestionada por un Centro de excelencia.
Autonomía frente a centralización Es posible que diferentes líderes deseen la propiedad separada de los datos. La autonomía favorece múltiples organizaciones de Data 360. La centralización favorece Data Cloud One. Un holding con filiales independientes permite a cada unidad de negocio ejecutar su propio Data 360.
Latencia y desempeño Afecta a la velocidad y la experiencia de las consultas, especialmente para organizaciones complementarias conectadas a un arrendatario de Data 360 entre regiones. Un equipo de ventas en Londres que consulta datos de un arrendatario de Data 360 en EE.UU. puede ver una latencia más alta.
Complejidad de integración Más arrendatarios de Data 360 = más oportunidades en curso, API y middleware. La consolidación simplifica la integración. Un minorista evita crear 10 oportunidades en curso de ETL consolidándolas en una configuración de Data Cloud One.
Región de origen de datos de copia cero Los requisitos de acceso entre regiones para algunos conectores pueden limitar la región o la ubicación de su organización de Data 360. Una compañía tiene una instancia de Snowflake en la región eu-west-1 de AWS. Pueden utilizar Cero copia para federar datos a Data 360 en su región, pero no pueden utilizar Cero copia para federar a Data 360 en la región de EE.UU.
Compatibilidad entre regiones de Private Connect A veces, la compatibilidad de Conexión privada depende de si el origen de datos está en la misma región que el arrendatario de Data 360. Una compañía tiene una instancia de Snowflake en la región aws-east-1 que desea conectar con Data 360 a través de copia cero. Solo pueden establecer una conexión de red de Conexión privada si la organización de inicio de Data 360 está en la misma región.
Costo y licencias Cada arrendatario de Data 360 agrega costo. La consolidación en menos instancias optimiza el gasto. Un proveedor de cuidados sanitarios reduce los costos de licencias adoptando Data Cloud One en vez de múltiples instancias independientes de Data 360.
Escalabilidad futura Las opciones de aprovisionamiento establecen hoy las bases para el crecimiento. Una compañía de SaaS comienza con una única instancia de Data 360 pero planea ampliar a Data Cloud One a medida que adquiere filiales con organizaciones de Salesforce.
Preparación de IA de toda la compañía Las funciones de IA y Agentforce requieren un arrendatario de Data 360 conectado en cada organización. Las decisiones de aprovisionamiento afectan al modo en que los modelos de IA se entrenan y activan en toda la compañía. Una compañía de servicios financieros unifica datos en Data Cloud One de modo que sus modelos de IA de Einstein tengan acceso a datos de clientes de toda la compañía.
## Casos de uso Existen tres casos de uso principales que requieren decisiones para el aprovisionamiento de Data 360g: - Selección de la organización de inicio - Aplicación de una estrategia de múltiples organizaciones - Colaboración de datos entre organizaciones de Data 360 ### Selección de la organización de inicio Cuando adquiere una licencia de Data 360, la instancia de Data 360 se aprovisiona en la organización de Salesforce asociada con esa licencia. Esta organización se conoce como la organización de inicio de Data 360. La organización de inicio es el anclaje para su instancia de Data 360. Esto incluye: - Gestión del almacenamiento y computación de Data 360 (en la región seleccionada en el aprovisionamiento). - Aplicación de políticas de administración, gobernanza y seguridad - Desempeño de ingreso, Armonización, Resolución de identidad, Segmentación y Activación de datos En escenarios de múltiples organizaciones, la organización de inicio gestiona la instancia central de Data 360 para otras organizaciones "compañeras" de Salesforce. **La organización de inicio:** - Determina la ubicación geográfica de su instancia de Data 360. - Determina quién es el propietario y el administrador de su instancia de Data 360. Los administradores de su organización de inicio de Data 360 pueden acceder a todos los datos ingresados en Data 360. - Controla las conexiones de organizaciones complementarias en una configuración de Data Cloud One. - Establece las bases para su estrategia de datos de compañía: cambiarla más adelante es difícil e interrumpe. Para obtener más información sobre las organizaciones de inicio de Data 360, consulte [Patrones y prácticas](/docs/architect/es-mx/fundamentals/guide/data360_integration_patterns_and_practices) de integración de Data 360. #### Decisión: ¿Organización existente o Nueva organización como la organización de inicio? La primera decisión importante es si aprovisionar Data 360 en una organización de producción existente o crear una nueva organización dedicada para actuar como la organización de inicio. Diagrama de decisiones mostrando la organización existente frente a la nueva organización como organización de inicio **Opción A: Aprovisionar datos 360 en una organización** existente **Funciona mejor para:** Clientes con una única organización de Salesforce o clientes de múltiples organizaciones que ya tienen una organización centralizada principal donde se ejecuta la mayoría de los procesos de negocio. Gráfico que muestra el aprovisionamiento de Data 360 en una organización existente - **Ventajas:** - Ruta más sencilla: Data 360 se aprovisiona donde residen sus datos de CRM. - Acceso inmediato a datos locales de Ventas, Servicio y Marketing. - No se requiere integración adicional. - Menos licencias y entornos para gestionar. - Acelera la adopción temprana, los pilotos y los casos de uso de producción. - **Desventajas:** - Puede heredar la deuda técnica o de gobernanza de una organización existente. - Si no existe ninguna “organización principal” única, la selección de una puede crear debates de propiedad. - Desempeño vinculado a la ubicación de la organización; puede no estar en sintonía con las necesidades de residencia de toda la compañía. - Si varias unidades de negocio utilizan organizaciones diferentes, el aprovisionamiento local puede llevar a la fragmentación si no se empareja con Data Cloud One. **Ejemplo:** Una compañía SaaS con una organización de Salesforce aprovisiona Data 360 en esa organización para unificar los datos de asistencia y suscripción de clientes. **Opción B: Aprovisionar Data 360 en una organización** nueva y exclusiva **Funciona mejor para:** Clientes con múltiples organizaciones de Salesforce que no pueden alinearse en una única organización principal, o empresas con un modelo de Centro de excelencia (CoE) sólido. Gráfico que muestra el aprovisionamiento de Data 360 en una nueva organización dedicada - **Ventajas:** - Borrón y cuenta nueva para la gobernanza, sin complejidades de organización heredadas. - Control centralizado entre múltiples líneas de negocio. - Flexibilidad para elegir una región basándose en necesidades de cumplimiento. - Actúa como una organización de “servicio compartido” neutral, no vinculada a una unidad de negocio. - Configure la futura arquitectura de Data Cloud One (organización de inicio con múltiples organizaciones complementarias). - **Desventajas:** - Los clientes deben otorgar licencias a una nueva organización de Salesforce para aprovisionar Data 360. - Integración adicional requerida para conectar la organización con Data 360 a través de una conexión complementaria de Data Cloud One. - Puede agregar gastos administrativos (gestión de usuarios, seguridad, identidad). - Tiempo de valor más lento en comparación con el aprovisionamiento en una organización de producción existente. **Ejemplo:** Una compañía multinacional de servicios financieros crea una organización de inicio exclusiva para aprovisionar Data 360\. Todas las organizaciones de unidades de negocio (Retail, Wealth, Commercial Banking) se conectan como organizaciones complementarias a través de Data Cloud One. **Criterios de decisión**
Consideración Organización existente como organización de inicio (Predeterminado preferido) Nueva organización como organización de inicio (alternativa)
Sencillez Se basa en la estructura de datos y usuarios existentes para una configuración más rápida.
Data 360 está integrado de forma predeterminada con la organización de inicio.
Requiere licencia y configuración de una nueva organización de Salesforce, así como gastos administrativos adicionales para gestionarla
Tiempo hasta valor Uso inmediato de datos de CRM locales Se requiere una rampa e integración más lentas.
Gobernanza Hereda el modelo de gobernanza básico de la organización existente: usuarios y conjuntos de permisos existentes (puede ser aceptable si la organización ya es central). Borrón y cuenta nueva para la gobernanza. Ideal para modelos dirigidos por COE.
Cumplimiento Residencia vinculada a la región de la organización existente Flexibilidad para seleccionar una región independiente de organizaciones existentes
Desempeño El mejor desempeño para consultas de CRM locales Dependiendo de la conectividad de la organización complementaria, ya sea la misma región o entre regiones que las otras organizaciones
Escalabilidad futura Funciona bien si se empareja con Data Cloud One. Más difícil cambiar más adelante si se selecciona la organización incorrecta Se amplía fácilmente con Data Cloud One. Diseñado para la neutralidad.
Costo Costo incremental inferior Mayor sobrecarga desde entornos adicionales
#### Recomendaciones Como principio general, utilice una organización principal existente como su organización de inicio para minimizar el esfuerzo inicial y acelerar la adopción. Solo cree una organización de inicio nueva y exclusiva si su estrategia de cumplimiento o gobernanza a largo plazo lo requiere. La creación de una nueva organización de inicio exclusiva es una opción común para grandes empresas con un Centro de excelencia (COE). **Entorno de organización única** Aprovisione Data 360 en su organización de producción existente. Esto maximiza la simplicidad y el valor inmediato. Evita gastos generales de integración innecesarios. **Entorno de múltiples organizaciones** Prefiera seleccionar una de sus organizaciones principales (normalmente aquella donde se ejecuta la mayoría de su negocio o la organización que sirve como su CRM centralizado) para actuar como la organización de inicio. Esto reduce la complejidad, minimiza el trabajo de configuración y le permite obtener el valor de Data 360 rápidamente. El uso de una organización principal existente también evita el costo y el esfuerzo de integración de la gestión de un nuevo entorno. **Cuándo considerar una organización de inicio nueva y exclusiva** La creación de una organización de inicio proporciona flexibilidad y neutralidad, pero con un tiempo de valor más lento en estos casos. - Si su organización tiene un Centro de excelencia (CoE) sólido y desea una gobernanza separada de las organizaciones de unidades de negocio. - Si ninguna organización existente es adecuada debido al cumplimiento o las restricciones organizativas. ### Aplicación de una estrategia de múltiples organizaciones #### El reto de múltiples organizaciones Las compañías a menudo operan múltiples organizaciones de Salesforce, y este no es un caso de borde, sino la norma. En febrero de 2024, aproximadamente 19.000 clientes de Salesforce ya ejecutaban más de una organización de Salesforce. ¿Por qué sucede esto? - **Adquisiciones y fusiones:** Las compañías recién adquiridas aportan sus propias instancias de Salesforce. - **Operaciones regionales:** Organizaciones separadas para UE, Norteamérica, Asia-Pacífico, etc., a menudo para satisfacer leyes de residencia de datos. - **Separación funcional:** Diferentes unidades de negocio (por ejemplo, Retail Banking, Wealth Management, Insurance) mantienen sus propias organizaciones para la autonomía. - **Aislamiento normativo o de seguridad:** Algunas industrias exigen organizaciones lógicamente distintas por motivos de cumplimiento. - **Por razones históricas o técnicas:** Con el tiempo, los clientes acumulan orgánicamente múltiples organizaciones. Cada motivo tiene sentido individualmente, pero juntos crean fragmentación de datos. Sin una capa unificadora, cada organización solo tiene una vista parcial del cliente. El reto arquitectónico: ¿Cómo unificar datos entre organizaciones en una única fuente de verdad respetando al mismo tiempo los requisitos de cumplimiento, gobernanza y autonomía? --- #### Data Cloud One Data Cloud One es la arquitectura de conectividad de múltiples organizaciones de Salesforce que permite a múltiples organizaciones de Salesforce compartir una única instancia de Data 360. Es el patrón recomendado para compañías con múltiples organizaciones de Salesforce. En cualquier clúster de Data Cloud One, se designa una organización de Salesforce como la organización de inicio, que aloja la instancia de Data 360. Otras organizaciones de Salesforce se conectan como organizaciones complementarias, consumiendo los datos y metadatos unificados desde Data 360 de la organización de inicio. Gráfico que muestra la arquitectura de Data Cloud One **Cómo funciona Data Cloud One** - **Ingreso y unificación de datos (Organización de inicio)** - Toda la configuración de ingreso de datos (Salesforce CRM, orígenes externos, transmisión, lote) se produce únicamente desde la organización de inicio. - El arrendatario de Data 360 vinculado a la organización de inicio realiza la Resolución de identidad, Armonización, Modelado y Unificación en perfiles de cliente de confianza. - La administración de Data 360, las políticas de gobernanza, el etiquetado y el enmascaramiento se aplican de forma centralizada desde la organización de inicio. - **Arquitectura de espacio de datos** - Desde la organización de inicio, los datos se organizan en espacios de datos, que actúan como contenedores lógicos para datos, metadatos y procesos. - Las compañías pueden crear espacios de datos para marcas, regiones o líneas de negocio. - Colaboración de espacio de datos: Desde la organización de inicio, los espacios de datos específicos se comparten de forma selectiva con organizaciones complementarias. Esto garantiza que solo los datos relevantes (y los metadatos asociados) fluyen a las organizaciones correctas. - **Compartir metadatos** Las organizaciones complementarias reciben definiciones de metadatos de la organización de inicio, incluyendo objetos de modelo de datos (DMO), esquema de perfil unificado, perspectivas calculadas, segmentos [y mucho más](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). Estos aparecen de forma nativa en la organización complementaria como si fueran activos locales, pero están vinculados a la organización de inicio. - **Capacidades en organizaciones de organización de inicio frente a organizaciones complementarias** El acceso a funciones varía entre organizaciones de inicio y complementarias. Las organizaciones complementarias no pueden ingresar o unificar datos y dependen de la organización de inicio para el ingreso, el modelado y la unificación. Las organizaciones complementarias pueden acceder a datos de Data 360 para potenciar funciones de plataforma con tecnología de Data 360, y pueden crear perspectivas, segmentos y flujos locales sobre los datos compartidos de confianza. En una visión futura, también pueden acceder a funciones de activación.
Capacidad Organización de inicio Organización complementaria
Conectar Configurar conectores, crear transmisiones de datos, ingresar o federar datos ✅ ❌
Armonizar y unificar Construir y ejecutar transformaciones de datos y resolución de identidad ✅ ❌
Gobernar datos seguros con espacio de datos y permisos ✅ ✅
Segmentar y predecir Crear segmentos, perspectivas y crear modelos de Einstein Studio ✅ ✅
Activar activaciones de Everywhere, acciones de datos ✅ ✅
Funciones de plataforma: Generador de solicitudes, flujos, reportes, enriquecimiento [y mucho más](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ✅ ✅
Funciones con tecnología de Data 360: Centro de prospección, funciones de Sales y Service Cloud, Agentforce y mucho más ✅ ✅
- **Paridad de funciones de plataforma** Desde la perspectiva de usuarios y constructores, una vez compartidos los metadatos, existen algunas diferencias funcionales entre organizaciones de inicio y complementarias en términos de uso de funciones de la plataforma Salesforce. La lista de funciones admitidas se puede encontrar en [Funciones de Data 360 en organizaciones de compañía](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). - Las funciones de la plataforma Salesforce (como Flujos, Reportes, Generador de solicitudes, tableros y otras herramientas nativas de la plataforma) funcionan en organizaciones domésticas y complementarias una vez que los metadatos están disponibles. - Las funciones con tecnología de Data 360, como Agentforce, Centro de prospección, funciones Sales Cloud Einstein y funciones de IA de Service Cloud, también funcionan a la perfección en organizaciones domésticas y complementarias. Algunas funciones pueden estar en su camino para alcanzar la compatibilidad completa, pero el objetivo general es tener paridad de funciones entre organizaciones de inicio y complementarias para todas las funciones entre nubes que dependen de Data 360. - **Modelo de consumo** Toda la actividad de la organización complementaria (consultas, ejecuciones de segmentos, flujos desencadenados por Data 360, uso de IA, registro de Capa de Trust de Einstein, etc.) consume créditos de Data 360 desde la organización de inicio. Flujos de consumo de una forma: los créditos se centralizan, se facturan y se realizan un seguimiento con respecto a la asignación de créditos de la organización de origen. Sin embargo, puede desglosar para ver cuántos créditos utilizó cada organización individual en Digital Wallet. - **Principio de diseño: Construcción horizontal** La construcción horizontal en Data 360 es un principio de diseño fundamental, implementado principalmente a través de Data Cloud One, que permite que una única instancia de Data Cloud abarque múltiples organizaciones de Salesforce CRM distintas. El objetivo es que cada nueva función publicada funcione en organizaciones de inicio y complementarias sin configuración adicional. Esta función garantiza que Data Cloud One no sea solo una opción de arquitectura de datos, sino un elemento fundamental de Salesforce Platform en adelante. --- #### Decisión: Múltiples organizaciones de datos frente a Datos compartidos 360 (Data Cloud One) Las compañías con múltiples organizaciones deben elegir cómo y dónde localizar Data 360 en su ecosistema. ¿Desea aprovisionar organizaciones independientes de Data 360 en cada organización, o utilizar Data Cloud One para unificar organizaciones bajo una única organización de inicio? **Opción A: Múltiples organizaciones** independientes de Data 360 Cada organización de Salesforce aprovisiona su propia instancia de Data 360. **Ventajas:** - **Autonomía:** Cada unidad de negocio o región controla su propio Data 360. - **Simplicidad en cada organización:** La gobernanza, la seguridad y las personalizaciones están traducidas. - **Cumplimiento normativo:** Útil cuando se requiere una separación regulatoria estricta (por ejemplo, los datos no deben cruzar fronteras). **Desventajas:** - **Silos de datos:** Los perfiles unificados no se pueden alcanzar entre organizaciones. - **Mayor costo:** Cada instancia requiere licencias, administración e integración. Los clientes terminan ingresando los mismos datos de origen varias veces entre múltiples organizaciones diferentes. - **Trabajo duplicado:** La resolución de identidad, la segmentación y el enriquecimiento deben repetirse en cada instancia de Data 360. **Opción B: One Shared Data 360 (Clúster de Data Cloud One)** Se proporciona un único Data 360 en una organización de inicio, con otras organizaciones de Salesforce conectadas como organizaciones complementarias. **Ventajas:** - **Fuente de verdad única (SSOT):** Todas las organizaciones comparten un modelo de datos unificado. - **Eficiencia de costos:** Gestione solo una licencia e infraestructura de Data 360. - **Gobernanza unificada:** Políticas, seguridad y controles de cumplimiento aplicados de forma centralizada. - **Enriquecimiento entre organizaciones:** Acceda a perfiles, perspectivas y segmentos armonizados entre organizaciones complementarias. - **Preparación de IA:** Un conjunto de datos de toda la compañía permite una mejor capacitación y activación de modelos de IA. - **Prueba futura:** Agregar nuevas organizaciones complementarias es sencillo, ya que no hay necesidad de nuevas organizaciones de Data 360. **Desventajas:** - **Preparación adicional:** One Data 360 requiere planificación para la conectividad de organización a organización de inicio. - **Consideraciones sobre la latencia:** Las organizaciones complementarias en diferentes regiones pueden ver consultas más lentas. - **Gobernanza compleja:** Si cada organización tiene necesidades de personalización diferentes, la regulación detallada puede ser compleja. **Opción C: Múltiples clústeres de** Data Cloud One En **ocasiones**, la gobernanza, el cumplimiento u otros requisitos de negocio pueden hacer que no sea práctico agrupar todas las organizaciones juntas. Esto puede llevar a la necesidad de implementar una solución híbrida en la que la compañía opera varias organizaciones de Data 360, cada una de las cuales es la organización de inicio para un clúster diferente de organizaciones complementarias. **Ejemplo:** Una corporación multinacional tiene organizaciones de Salesforce en varias regiones, incluyendo Europa, EE.UU. y Asia. Para cumplir con las leyes de residencia de datos regionales, proporcionan un Data 360 para cada región separada. **Criterios de decisión**
Consideración Múltiples organizaciones independientes de Data 360 Uno Datos compartidos 360 (Data Cloud One)
Autonomía Alta autonomía para cada organización o unidad de negocio Gobernanza centralizada, menor autonomía por organización
Cumplimiento Útil cuando se requiere una separación estricta (por ejemplo, leyes regionales) Funciona mejor cuando la residencia permite la centralización
Costo Mayores costos de licencia y administración Más rentable; una licencia para muchas organizaciones
Gobernanza Fragmentado; las políticas difieren por organización Políticas coherentes y centralizadas entre organizaciones
Silos de datos Cada organización con su propia vista Sin Enterprise 360 Conjunto de datos unificado, sin duplicaciones
IA/Analytics Limitado a los datos de cada organización Modelos de toda la compañía con mejor precisión
Complejidad Más instancias para gestionar, más integraciones Arquitectura más sencilla, menos piezas móviles
Desempeño Lo mejor para casos de uso intraorganización Posible aumento de la latencia con acceso de organización complementaria
--- #### Recomendaciones **Patrón preferido: Data Cloud One** Para simplificar la gobernanza y optimizar el costo entre compañías de múltiples organizaciones, utilice una única organización de inicio con organizaciones complementarias conectadas. **Cuándo utilizar múltiples organizaciones de Data 360:** Solo utilice múltiples organizaciones de Data 360 si el cumplimiento, la residencia o la autonomía organizativa lo requieren estrictamente (por ejemplo, si las operaciones europeas deben permanecer completamente separadas de las operaciones de EE.UU. debido a la regulación). **Cómo elegir la organización de inicio en Data Cloud One:** Comience considerando una de sus organizaciones principales, normalmente donde se ejecuta la mayoría de los negocios. El aprovisionamiento de Data 360 puede minimizar la complejidad y maximizar el valor temprano. Considere crear una organización de inicio dedicada gestionada por un equipo de COE, solo si ninguna organización existente es adecuada. **Principio general:** En entornos de múltiples organizaciones, minimice el número de organizaciones de Data 360. Favorezca Data Cloud One como el patrón predeterminado para reducir la duplicación, activar la preparación para la IA y simplificar la gobernanza. ### Colaboración de datos entre organizaciones de Data 360 #### La necesidad de compartir datos Aunque Data Cloud One es el enfoque recomendado para la mayoría de las compañías, existen escenarios donde los clientes deben aprovisionar múltiples instancias de Data 360, incluyendo: - **Cumplimiento regional.** Un minorista multinacional aprovisiona un Data 360 en la UE y otro en EE.UU. La colaboración de datos de Data 360 a Data 360 permite a la compañía crear perspectivas desde datos locales y seguir compartiendo la perspectiva con la sede central de EE.UU. - **Colaboración de unidad de negocio.** Un conglomerado ejecuta organizaciones de Data 360 separadas para Retail y Insurance. El uso compartido de datos entre organizaciones de Data 360 permite a los usuarios acceder a un único origen de datos autorizado sin moverse o copiar. Con el uso compartido de datos entre organizaciones de Data 360, la organización de Seguros recibe el segmento “Cliente de alto valor” de Retail para campañas de venta cruzada dirigidas. - **Fusiones y adquisiciones.** Una compañía matriz adquiere una filial con su propio Data 360\. Con dos instancias para gestionar, la retención de silos de datos a corto plazo mantiene la seguridad de los datos y la integridad de SSOT. Simultáneamente, compartir datos entre dos instancias de Data 360 permite la colaboración necesaria durante la transición. - **Tableros ejecutivos federados.** Una multinacional distribuida entre continentes aprovisiona organizaciones de Data 360 individuales por región. Los ejecutivos desean una vista de desempeño trimestral federada. Cada Data 360 regional comparte perspectivas calculadas agregadas con una “Organización ejecutiva”, permitiendo la creación de reportes de toda la compañía. #### Cómo funciona la colaboración de datos Cuando existen múltiples organizaciones de Data 360, la unificación entre ellas no es automática. La colaboración de datos de Data 360 a Data 360 permite a los clientes compartir objetos específicos entre instancias de Data 360 sin duplicaciones ni oportunidades en curso personalizadas. Es un mecanismo de colaboración de metadatos de copia cero diseñado para la colaboración entre organizaciones de Data 360. - Cada Data 360 se aprovisiona en su propia organización de inicio. - Los administradores pueden crear una colaboración de datos: una agrupación de objetos específicos que desean compartir. - El acceso a los datos seleccionados se comparte con Data 360 de una organización de destino, donde los objetos aparecen como si estuvieran definidos localmente. Solo se comparte el acceso, los datos subyacentes permanecen en Data 360 de origen. - Las etiquetas no se comparten. Solo los objetos sin procesar están disponibles; la organización de destino debe volver a aplicar cualquier etiqueta de gobernanza, operativa o de IA según sea necesario. #### Diferencias clave con Data Cloud One - En Data Cloud One, múltiples organizaciones complementarias comparten una única instancia de Data 360. Para garantizar la coherencia, las funciones de plataforma como Agentforce, Centro de prospección y Tableau Next se ejecutan en los mismos datos subyacentes. - Al utilizar la colaboración de datos entre organizaciones de Data 360, cada organización tiene su propio Data 360\. Funciones como Agentforce en la organización A y la organización B funcionan cada una de forma independiente en su instancia local. No se produce ninguna colaboración automáticamente: se deben crear colaboraciones de datos deliberadas solo para colaborar en objetos específicos. #### Pros y contras de la colaboración de datos entre organizaciones de Data 360
Factor Ventajas Contras
Residencia de datos Admite la separación regional mientras activa la colaboración. No elimina la necesidad de gestionar múltiples organizaciones de Data 360.
Duplicación de datos Cero copia; sin duplicación de objetos. Requiere la selección deliberada de objetos para su inclusión en cada colaboración de datos.
Gobernanza La colaboración es explícita y deliberada (a nivel de objeto). No fluyen etiquetas ni políticas; la organización de destino debe volver a aplicar la gobernanza.
Complejidad Activa la colaboración selectiva sin centralización. Requiere la gestión de múltiples organizaciones de Data 360 y colaboraciones de datos.
**IA/Analytics** Es posible realizar análisis/IA regionales; las perspectivas se pueden compartir entre organizaciones. Ninguna IA de toda la compañía a menos que se compartan datos deliberadamente.
**Funciones de plataforma** Las funciones con tecnología de Data 360 de cada organización se ejecutan de forma independiente. Sin colaboración automática. Riesgo de duplicación si no se diseña cuidadosamente.
Costo Puede reducir la necesidad de oportunidades en curso de ETL. Aún incurre en el costo de múltiples organizaciones de Data 360. Consume créditos para consultas de datos y colaboración de datos.
#### Criterios de decisión
Consideración Data Cloud One (Preferido para múltiples organizaciones) Colaboración de datos entre organizaciones de Data 360
Fuente de verdad única Sí: todas las organizaciones comparten un modelo de datos. No: cada Data 360 tiene su propio modelo de datos.
Cumplimiento Solo funciona cuando la residencia permite la centralización. Se necesita cuando las leyes de residencia impiden la centralización.
Gobernanza Centralizado, coherente. Colaboraciones a nivel de objeto federadas y deliberadas.
Complejidad Menos piezas móviles, más sencillo. Más complejo: requiere colaboraciones de datos de configuración y múltiples organizaciones de datos.
IA/Analytics Modelos de IA de toda la compañía. IA regional. Comparta perspectivas de forma selectiva.
Funciones de plataforma Datos compartidos 360 significa que todas las funciones funcionan de forma coherente en casa + compañeros. Las funciones se ejecutan de forma independiente en cada Data 360; la colaboración debe ser explícita.
#### Recomendaciones **Si su compañía tiene múltiples organizaciones de Data 360** - Utilice la colaboración de datos entre organizaciones de Data 360 para colaborar entre ellas en vez de crear oportunidades en curso personalizadas o duplicar datos. - Comparta objetos específicos (DMO, perspectivas calculadas, segmentos) creando colaboraciones de datos y otorgándolas a organizaciones de destino. - Las etiquetas no se comparten: la organización receptora debe volver a aplicar etiquetas para la gobernanza, la clasificación o el enriquecimiento de la IA. **Utilizar la colaboración de datos entre organizaciones de Data 360** - Para cumplir los requisitos normativos que impiden la centralización. - Para mantener la autonomía de la unidad de negocio mientras activa la colaboración selectiva. - Para proporcionar tableros ejecutivos federados entre múltiples regiones. - Para salvar escenarios de fusiones y adquisiciones donde la consolidación no es posible de inmediato. **Diseñar cuidadosamente** Trate la colaboración de datos de Data 360 a Data 360 como una estrategia de federación, no como un reemplazo de Data Cloud One. - Utilice colaboración específica de objeto. - Evite compartir en exceso. - Alinee colaboraciones de datos con necesidades de negocio y cumplimiento. #### Recuerde La planificación de su estrategia de datos para el aprovisionamiento de Data 360 es una decisión arquitectónica crítica a largo plazo que debe abordarse en toda la compañía, no organización por organización. Esta opción estratégica temprana dicta cómo se unifican los datos de los clientes, cómo se aplica la gobernanza y cómo se amplían las funciones esenciales de la plataforma (especialmente IA y análisis) en toda la organización. Planifique modelos de propiedad y gobernanza con antelación y evite accesos directos a corto plazo que conducen a la fragmentación y complejidad aumentada más adelante. ## Recursos [¿Qué es Customer 360?](https://www.salesforce.com/products/what-is-customer-360/) [Patrones y prácticas de integración de Data 360](/docs/architect/es-mx/fundamentals/guide/data360_integration_patterns_and_practices) [Arquitectura de Data 360](/docs/architect/es-mx/fundamentals/guide/data-360-architecture) [Arquitectura de seguridad de Data 360](/docs/architect/es-mx/fundamentals/guide/data360_security_architecture) **Sobre los autores** Kunal Goyal es Director de Gestión de productos de Salesforce, centrado en el avance de la arquitectura de múltiples organizaciones y la capacidad de ampliación dentro de Data 360.Desde 2017, lidera múltiples iniciativas y productos centrados en la colaboración entre organizaciones y el diseño de sistemas de múltiples arrendatarios. Kunal es uno de los Prospectos de arquitectura de mejores prácticas de Data 360 y el propietario del producto para las experiencias de Data Cloud One, configuración, aprovisionamiento y administración. Erin Wagner Tidwell es redactora técnica principal y diseñadora de contenido para Data 360\. Está en Salesforce desde 2013\. Se dedica a facilitar la comprensión y el uso de Data 360 a través de documentación técnica clara, coherente y precisa y comunicación en aplicación. Yugandhar Bora es Arquitecto de Ingeniería de Software en Salesforce, especializado en arquitectura de datos dentro de la plataforma Aplicaciones de datos e inteligencia. Lidera iniciativas de la junta de revisión de arquitectura de negocio (EARB) centradas en la gobernanza de datos y modelos de datos unificados, mientras contribuye a soluciones de aprovisionamiento de plataforma automatizadas. Samarpan Jain es Arquitecto principal de Salesforce especializado en Commerce Cloud, integración de plataforma y arquitectura interinstitucional. Uno de los empleados con más antigüedad de Salesforce, lidera iniciativas clave que incluyen el cumplimiento de residencia de datos para clientes gubernamentales y sistemas de atribución de uso de Data 360. # Uso de las herramientas y los patrones correctos para arquitecturas dirigidas por eventos Las arquitecturas dirigidas por eventos admiten la producción y el consumo eficientes de eventos, que comunican cambios de estado del sistema o la aplicación. Estas arquitecturas permiten conexiones flexibles entre sistemas y admiten procesos y actualizaciones casi en tiempo real que funcionan entre sistemas. Aunque las ventajas de las arquitecturas dirigidas por eventos son fáciles de ver, los detalles de implementación no siempre son tan claros. ¿Qué funciones necesita tener en cuenta en patrones arquitectónicos dirigidos por eventos? ¿Qué problemas específicos resuelven estos patrones? ¿Qué consideraciones especiales se aplican a sus soluciones y cuáles son los patrones óptimos para abordarlas? ## Descripción general de guía Esta guía presenta patrones utilizados para crear arquitecturas dirigidas por eventos óptimas cuando se trabaja con tecnologías de Salesforce. También analiza herramientas de eventos disponibles en Salesforce y proporciona recomendaciones de herramientas para una selección de casos de uso. Para obtener información acerca de integraciones a nivel de datos que implican Salesforce, consulte nuestra [Guía de decisiones](/docs/architect/es-mx/decision-guides/guide/data-integration) de integración de datos. ## Comida para llevar - **Utilice arquitecturas dirigidas por eventos para procesos que no requieren respuestas síncronas a solicitudes.** Los patrones descritos en esta guía están diseñados para la coherencia, la capacidad de ampliación y la reutilización de datos, lo que ayuda a mantener la deuda técnica al mínimo a medida que evoluciona el panorama de aplicaciones de su organización. (Consulte [Bien arquitectado - Fiabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html) para obtener más información.) - **Si MuleSoft u otra solución de Enterprise Service Bus (ESB) forma parte de su panorama existente, utilícela donde sea posible.** Estas soluciones están creadas específicamente para admitir patrones de arquitectura dirigidos por eventos y tienen potentes funciones que le permiten reutilizar integraciones en su compañía. - **Utilice la API Pub/Sub para cualquier patrón de publicación/suscripción futuro en vez de crear sus propios controladores de eventos utilizando otras API, incluyendo la API de transmisión.** Ahora que la API Pub/Sub está disponible de forma general, utilícela para cualquier nuevo patrón de publicación/suscripción. Planifique migrar comunicaciones de eventos existentes utilizando otras API de plataforma, como la API de transmisión o servicios Apex personalizados, a la API Pub/Sub cuando sea factible hacerlo. - **Los eventos de plataforma y Captura de datos de cambios (CDC) son los mecanismos preferidos para publicar cambios de registro y campo que necesitan ser consumidos por otros sistemas.** No recomendamos utilizar PushTopic y eventos genéricos para nuevas implementaciones. Salesforce seguirá admitiendo PushTopic y eventos genéricos dentro de las funciones actuales, pero no tiene intención de realizar más inversiones en esta tecnología. ## Productos en ámbito
Plataforma Salesforce Salesforce Platform es una plataforma integral dirigida por IA que unifica empleados, agentes de IA autónomos, datos de compañía y aplicaciones en un único sistema de confianza para mejorar la productividad y la experiencia del cliente. Permite la creación de una "compañía agencia" conectando aplicaciones Customer 360, Data Cloud y Slack para la automatización de extremo a extremo.
MuleSoft MuleSoft es la plataforma de integración líder de Salesforce que permite a las organizaciones conectar aplicaciones, datos y dispositivos en entornos locales y de nube. MuleSoft es una plataforma que proporciona a TI las plataformas para desbloquear datos entre sistemas, desarrollar marcos de trabajo de automatización e integración ampliables y crear experiencias conectadas diferenciadas rápidamente.
## Puntos de decisión Las arquitecturas dirigidas por eventos (EDA) se recomiendan para escenarios que requieren notificaciones casi en tiempo real, distribuyendo la carga de procesamiento para mensajes de gran volumen o complejos e integrando sistemas como IoT y dispositivos móviles que requieren resiliencia de conectividad a través de colas. Sin embargo, los EDA no deben implementarse para procesos que exigen respuestas humanas inmediatas y síncronas, ya que están diseñados para la ejecución asíncrona. Tampoco se ajustan bien si los datos de origen cambian con tan poca frecuencia que un patrón más sencillo como el procesamiento por lotes sería suficiente. ### Cuándo utilizar una arquitectura dirigida por eventos Estos son varios escenarios comunes que a menudo se ajustan bien a una arquitectura dirigida por eventos:
Punto de decisiónDirectrices
Notificaciones casi en tiempo realLos patrones de arquitectura dirigidos por eventos como publicación/suscripción, fanout y transmisión tienden a funcionar bien en escenarios donde múltiples aplicaciones necesitan ser notificadas de cambios de estado o actualizaciones de registros casi en tiempo real.
Procesamiento paraleloPatrones como publicar/suscribir tienden a funcionar bien en escenarios donde grandes volúmenes de datos o mensajes altamente complejos requieren distribuir la carga de procesamiento entre múltiples sistemas.
Lecturas de gran volumenLos patrones Mensajes pasados y Colocación en cola se utilizan habitualmente en escenarios donde las organizaciones experimentan aumentos y el volumen de mensajes que se están produciendo puede superar la capacidad de los suscriptores para procesarlos inmediatamente.
Escrituras de gran volumenLos patrones de Transmisión y Colas funcionan bien en muchos escenarios donde las organizaciones experimentan aumentos en el número de mensajes producidos.
Envío de los mismos datos a diferentes sistemasAunque la publicación/suscripción tiende a ser una solución bastante común para organizaciones que necesitan enviar los mismos datos a múltiples sistemas, la mayoría de los patrones cubiertos aquí pueden solucionarla. Asegúrese de revisarlos en detalle para encontrar el mejor ajuste.
Introducción frecuente de nuevos sistemas o dispositivosLos patrones de publicación/suscripción, Transmisión y Colocación en cola tienden a funcionar bien para escenarios donde el panorama general tiende a estar en flujo, con nuevos sistemas y dispositivos agregados regularmente. En este escenario, un nuevo sistema o dispositivo simplemente necesita convertirse en un suscriptor del bus de eventos o asociado con una cola, para comenzar a recibir mensajes en vez de requerir una integración de punto a punto personalizada.
Dispositivos IoTDebido a que los dispositivos de IoT normalmente entregan actualizaciones frecuentes y también pueden generar una oleada de mensajes en algunos escenarios, los patrones de Transmisión y Colocación en cola tienden a funcionar bien al integrarlos en un entorno de TI.
Dispositivos y sistemas móviles sin conexiónLos dispositivos móviles que necesitan trabajar en áreas con acceso a Internet de baja calidad o inexistente o sistemas que podrían estar sin conexión en el momento de la entrega de los mensajes se beneficiarán del patrón Colas, que les permite conectarse a sus colas y recuperar cualquier mensaje relevante una vez que vuelvan a estar conectados.
La mayoría de las grandes organizaciones tienen escenarios de TI complejos que tienen una combinación de sistemas con diferentes funciones. Es posible, o quizás probable, que su organización tenga sistemas heredados que no admitan integraciones dirigidas por eventos. También puede tener casos de uso donde las integraciones dirigidas por eventos no tienen sentido, incluso si los sistemas las admitirán (por ejemplo, transferencias de archivos SFTP desde terceros). Si da un paso atrás y observa el panorama de TI de su organización en su conjunto, lo más probable es que, al igual que con otras soluciones arquitectónicas, emplee una mezcla de patrones para dar cobertura a diferentes escenarios. Cuando decida hacer que la gestión de eventos sea su enfoque preferido para las integraciones, piense en ella como otra herramienta en su caja de herramientas. Puede y debe utilizarse en los escenarios correctos, pero no es un enfoque a imponer en cada sistema. Desarrollar una estrategia de integración integral le ayudará a determinar cuándo los patrones descritos en esta guía pueden o no ser apropiados. ### Cuándo no utilizar una arquitectura dirigida por eventos Muchos escenarios requieren arquitecturas dirigidas por eventos, y en algunos escenarios, las arquitecturas dirigidas por eventos funcionarán incluso si no son las más adecuadas. Pero en algunos escenarios, las arquitecturas dirigidas por eventos simplemente no se deben utilizar. Estas son algunas preguntas de punto de decisión para ayudarle a identificar estos escenarios:
Punto de decisiónDirectrices/Preguntas para formular
Requisitos de negocio¿Existe una necesidad de negocio genuina para cualquiera de las funciones descritas en la sección [Cuándo utilizar una arquitectura dirigida por eventos](#cuándo utilizar una arquitectura dirigida por eventos)?
Requisitos técnicos¿La integración que está diseñando se ajusta de forma obvia a un patrón diferente, como la virtualización de datos, los lotes o las solicitudes/respuestas? En otras palabras, ¿está intentando encajar una clavija cuadrada en un agujero redondo?
Procesos que requieren que los humanos esperen respuestasCualquier integración que implique un humano esperando una respuesta del sistema de destino no es una buena opción para arquitecturas dirigidas por eventos, ya que están diseñadas para la ejecución asíncrona y no pueden garantizar un tiempo de respuesta. Considere si procesos como este son óptimos para su organización antes de implementar soluciones técnicas. Consulte [Well-Architected - Operational Excellence](/docs/architect/es-mx/well-architected/guide/operational-excellence.html) para obtener más información.
Cambiar datos de origen con poca frecuenciaSi los datos en su sistema de origen cambian con tan poca frecuencia que las actualizaciones periódicas son suficientes, es probable que pueda simplificar su arquitectura utilizando [patrones por lotes] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) en vez de patrones dirigidos por eventos.
Requisitos de implementación¿La mayoría de los sistemas implicados en su solución admiten arquitecturas dirigidas por eventos? ¿Qué se requeriría para utilizar arquitecturas dirigidas por eventos con los sistemas que no las admiten (por ejemplo, actualizaciones, personalizaciones o middleware)? ¿Qué nivel de esfuerzo sería necesario para cumplir estos requisitos?
Estabilidad de estructura de mensajes¿Con qué frecuencia tendrán que cambiar sus estructuras de mensajes? ¿Qué sistemas se verán afectados por dicho cambio y cuál será el proceso de rehabilitación?
Gobernanza organizativa¿Tiene una estructura de gobernanza establecida para garantizar que todas las partes interesadas estén informadas y puedan ponderar los cambios en las estructuras de mensajes, desencadenadores y otras decisiones relacionadas con la arquitectura y los procesos?
Conjuntos de habilidades requeridos¿Tiene su personal experiencia con arquitecturas dirigidas por eventos y sabrán cómo brindarles asistencia?
## Casos de uso Hay una variedad de patrones de arquitectura dirigidos por eventos. Algunos son patrones de propósito general que se pueden aplicar en casos de uso que no tienen ningún requisito especial fuera de estar dirigidos por eventos; por ejemplo, consulte [Bien arquitectado: fiabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html). Otros patrones son aplicables a los casos de uso específicos tratados aquí, como integraciones que implican grandes volúmenes de datos o escenarios que requieren una retención de mensajes más larga. ### Patrones de un vistazo La tabla siguiente compara atributos de los patrones descritos en este documento. Utilícelo como una referencia rápida cuando necesite identificar posibles patrones para un caso de uso concreto.
PatrónCasi en tiempo realCopiar mensaje exclusivoEntrega de garantíaReducir el tamaño de mensajesTransformar datos
Publicar / Suscribir✓✓✓
Fanout✓✓✓
Mensajes pasados✓✓✓✓
Transmisión✓✓✓
Colocación en cola✓✓✓
### Herramientas para arquitectura dirigida por eventos Salesforce ofrece múltiples herramientas para ayudarle a solucionar sus casos de uso dirigidos por eventos. Esta tabla contiene una descripción general de alto nivel de las herramientas disponibles.
HerramientaDescripciónHabilidades requeridas
MuleSoftPlataforma AnypointPlataforma que activa la integración de datos utilizando capas de API.Código pro
Conector Salesforce Pub/SubAPI de Connector para Pub/Sub, que proporciona una única interfaz para publicar y suscribirse a eventos de plataforma, eventos de monitoreo de eventos en tiempo real y eventos Captura de datos de cambios.Código pro
MuleSoft Anypoint JMS ConnectorConector que permite enviar y recibir mensajes a colas y temas para cualquier servicio de mensajes que implemente la especificación Servicio de mensajes Java (JMS).Código pro
MuleSoft Anypoint Apache Kafka ConnectorConector para mover datos entre Apache Kafka y aplicaciones y servicios de negocio.Código pro
Conector de consola Anypoint de MuleSoftUn conector para corredores de eventos PubSub+ de Solace con integración de API nativa utilizando el SDK de Java JCSMPCódigo pro
MuleSoft Anypoint MQ ConnectorUn servicio de mensajería en la nube de múltiples arrendatarios que permite a los clientes realizar mensajería asíncrona avanzada entre sus aplicaciones.Código pro
MuleSoft Anypoint MQTT ConnectorUna extensión MuleSoft que cumple el protocolo MQTT (Message Queing Telemetry Transport).Código pro
Conector AMQP de Mulsoft AnypointUn conector que permite a su aplicación publicar y consumir mensajes utilizando un broker compatible con AMQP 0.9.1.Código pro
API dirigida por eventos de MuleSoft Anypoint (ASync)Lenguaje que distingue entre la industria y que admite la publicación de API dirigidas por eventos separándolas en capas de evento, canal y transporte.Código pro
MuleSoft Anypoint MQServicio de mensajería en la nube de múltiples arrendatarios que permite a los clientes realizar mensajería asíncrona avanzada entre sus aplicaciones.Código pro
Transmisiones de datos de MuleSoft AnypointMarco de trabajo disponible en MuleSoft Anypoint para publicar y suscribirse a datos de transmisión.Código pro
Plataforma SalesforceApache Kafka on HerokuComplemento de Heroku que proporciona Apache Kafka como un servicio con integración de plataforma completa en la plataforma Heroku.Código pro
Captura de datosRegistro de eventos de cambio, que publica los cambios en registros de Salesforce. Los cambios incluyen la creación de un nuevo registro, actualizaciones en un registro existente, la eliminación de un registro y la anulación de la eliminación de un registro.Código bajo a código profesional
Mensajes salientesAcciones que envían mensajes XML a extremos externos cuando se actualizan valores de campo en Salesforce.Código bajo
Eventos de plataformaMensajes seguros y ampliables que contienen datos de eventos personalizados.Código bajo a código profesional
API Pub/SubAPI que activa suscripciones a eventos de plataforma, eventos de Captura de datos de cambios y/o eventos de Monitoreo de eventos en tiempo real.Código pro
Retransmisiones de eventosActiva eventos de plataforma y Captura de datos de cambios para enviar desde Salesforce a Amazon EventBridge. Tenga en cuenta que las retransmisiones de eventos solo se conectan a AWS Eventbridge.Código bajo
### Publicar/Suscribir Cuando un registro crítico cambia de estado en una aplicación principal (por ejemplo, el estado de un pedido pasa de "Procesando" a "Enviado"), es probable que varios otros sistemas requieran una notificación casi en tiempo real para realizar sus tareas respectivas. Una necesidad de negocio específica surge cuando el volumen de estos cambios es alto y los mensajes son complejos, lo que hace que las integraciones punto a punto tradicionales sean onerosas y difíciles de mantener. Establecer conexiones frágiles y personalizadas para cada aplicación dependiente individual lleva a deudas técnicas e inhibe la capacidad de la organización de ampliarse rápidamente. Se necesita un enfoque de integración sólido para gestionar estas sincronizaciones de datos frecuentes sin acoplar el sistema de origen directamente a cada sistema consumidor. #### El patrón Publicar/Suscribir El siguiente diagrama representa un patrón típico de publicación/suscripción con múltiples publicadores y suscriptores compartiendo datos a través de un bus de eventos. Este patrón fundacional forma la base para los patrones más específicos que se pueden encontrar en el resto de esta guía. Algunas características clave de este patrón son: - No hay conexión directa entre publicadores y suscriptores. Los publicadores simplemente envían mensajes a un bus de eventos, que los transmite a cualquier otro sistema que desee escucharlos. - El mismo sistema puede ser un publicador y un suscriptor. - Los sistemas pueden publicar o suscribirse a múltiples tipos de eventos. - Al igual que con todos los patrones de esta guía, el patrón de publicación/suscripción recae en una categoría de patrón de integración general conocida como invocación de procedimiento remoto (RPI) o simplemente ["disparar y olvidar".](/docs/architect/es-mx/fundamentals/guide/integration-patterns#invocación-de-procesos-remotos-disparar-y-olvidar) Este diagrama Nivel 2 muestra un ejemplo del patrón de publicación / suscripción que incluye múltiples publicadores, múltiples suscriptores y múltiples eventos que se entregan a través de canales en un bus de eventos. En este patrón, el mismo sistema puede ser un publicador y un suscriptor y un sistema puede suscribirse a múltiples eventos. #### Herramientas relevantes para el patrón Publicar/Suscribir
Comportamiento y flujo de eventosConsideraciones sobre la carga
Herramientas disponiblesHabilidades requeridasPublicar víaSuscribirse a travésPeriodo de reproducciónEstructura de cargaLímites de carga
MuleSoftPlataforma AnypointCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector Salesforce Pub/SubCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint JMS ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint Apache Kafka ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector de consola Anypoint de MuleSoftCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQ ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQTT ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector AMQP de Mulsoft AnypointCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
API dirigida por eventos de MuleSoft Anypoint (ASync)Código proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Plataforma SalesforceApache Kafka on HerokuCódigo proAPI, registrar cambios en Postgres de HerokuN/A1-6 semanasUsuario definidoUsuario definido
Captura de datosCódigo bajo a código profesionalCambios de registroApex, API, componentes web Lightning (LWC)3 díasPredefinido1 MB
Mensajes salientes*Código bajoReglas de flujo y flujo de trabajoN/A24 horasUsuario definido100 notificaciones por mensaje
Eventos de plataformaCódigo bajo a código profesionalAPI, Apex, FlujoApex, API, Flow, LWC3 díasUsuario definido1 MB
API Pub/SubCódigo proAPI o API Pub/Sub, Apex, FlujoAPI Pub/Sub3 díasUsuario definido1 MB
Retransmisiones de eventos**Código bajoEventos de plataforma, Captura de datos de cambiosAPI3 díasUsuario definido1 MB
*Salesforce seguirá admitiendo mensajes salientes dentro de las funciones actuales, pero no tiene intención de realizar más inversiones en esta tecnología. **Las retransmisiones de eventos solo se conectan a AWS Eventbridge
### Fanout Cuando una organización necesita enviar actualizaciones instantáneas a un gran número de aplicaciones cliente, como notificaciones distribuidas o mensajes SMS a dispositivos móviles, el proceso tradicional de crear transmisiones exclusivas para cada destinatario se convierte rápidamente en un cuello de botella de capacidad de ampliación. La necesidad de negocio principal, en este caso, es la distribución rápida y de alto desempeño de una sola información (como una alerta de cuenta o un aviso de cambio de servicio crítico) a numerosas aplicaciones de extremo de forma simultánea. Un enfoque simplificado para cumplir este requisito implica el enrutamiento de todos los mensajes a través de una única cola, que actúa como el punto central de la información de eventos para todos los sistemas que consumen. Este enfoque mejora el desempeño eliminando la necesidad de gestionar muchas copias de mensajes separadas. #### El patrón Fanout Con el patrón fanout, los mensajes se entregan a uno o múltiples destinos (es decir, clientes o suscriptores que escuchan) a través de una única cola de mensajes. Los suscriptores recuperan el mismo mensaje de la cola, en vez de su propia copia exclusiva. (Tenga en cuenta que aunque esto mejora el desempeño, también puede hacer más difícil verificar si un suscriptor concreto recibió o no el mensaje.) Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo del patrón de abanico. Representa un evento que se publica y se escribe en una única cola cuando se modifica un registro a través de una interacción de usuario, un flujo o un trabajo por lotes. El sistema de suscriptor tiene múltiples servicios que reciben el mismo evento desde la cola de mensajes. #### Herramientas relevantes para el patrón Fanout
Comportamiento y flujo de eventosConsideraciones sobre la carga
Herramientas disponiblesHabilidades requeridasPublicar víaSuscribirse a travésPeriodo de reproducciónEstructura de cargaLímites de carga
MuleSoftMuleSoft Anypoint JMS ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector Salesforce Pub/SubCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint Apache Kafka ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector de consola Anypoint de MuleSoftCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQ ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQTT ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector AMQP de Mulsoft AnypointCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Plataforma SalesforceApache Kafka on HerokuCódigo proAPI, registrar cambios en Postgres de HerokuN/A1-6 semanasUsuario definidoUsuario definido
Captura de datosCódigo bajo a código profesionalCambios de registroApex, API, componentes web Lightning (LWC)3 díasPredefinido1 MB
Eventos de plataformaCódigo bajo a código profesionalAPI, Apex, FlujoApex, API, Flow, LWC3 díasUsuario definido1 MB
API Pub/SubCódigo proAPI Pub/Sub o Apex, API, FlujoAPI Pub/Sub3 díasUsuario definido1 MB
Retransmisiones de eventos*Código bajoEventos de plataforma, Captura de datos de cambiosAPI3 díasUsuario definido1 MB
*Las retransmisiones de eventos solo envían datos a AWS Eventbridge
### Mensajes pasados Algunos escenarios de eventos se caracterizan por una afluencia significativa de volumen de mensajes que amenaza con abrumar la capacidad de los procesos de sincronización y transformación, o por una lógica compleja de múltiples pasos requerida para procesar y transformar datos de eventos. Algunos ejemplos incluyen: - **Picos de volumen estacionales:** Puede haber picos de volumen que los minoristas online experimentan cuando una selección de sus productos está "en temporada". Cuando un gran número de clientes están realizando compras al mismo tiempo, el número de eventos generados puede superar temporalmente la capacidad de los procesos de sincronización y transformación. Consulte [Bien arquitectado - Fiabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html#scalability-and-capacity-planning) para obtener más información. - **Gestión de casos o reclamaciones:** Las compañías basadas en servicio pueden experimentar aumentos en el número de casos o reclamaciones durante cortes. - **Transformaciones de datos complejas:** Las organizaciones que requieren lógica compleja para transformar mensajes a menudo están preocupadas por que los eventos se generen más rápido de lo que se pueden transformar. #### El patrón de mensajes pasados Este patrón soluciona el reto de que los mensajes se generen más rápido de lo que se pueden transformar. Garantiza que los grandes volúmenes de mensajes y las manipulaciones de datos requeridas se puedan gestionar de forma fiable, incorporando una plataforma de mensajes de transmisión y segmentando la lógica de gestión de mensajes en componentes exclusivos. El patrón Mensajes pasados funciona segmentando la lógica de gestión de mensajes en múltiples componentes: - Un componente gestiona el enrutamiento de mensajes, determinando las transformaciones requeridas y el destino final. - Un conjunto separado de componentes gestiona diferentes capas de transformación de mensajes (por ejemplo, asignaciones de campos, relaciones de objetos, etc.). - El último componente redacta el mensaje modificado final. Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo de un flujo de proceso para el patrón de mensajes pasados que incluye un publicador, un suscriptor y un mensaje. El mensaje se divide en múltiples partes, que se transforman individualmente y luego se vuelven a ensamblar antes de enviarse al suscriptor. #### Herramientas relevantes para el patrón de mensajes pasados
Comportamiento y flujo de eventosConsideraciones sobre la carga
Herramientas disponiblesHabilidades requeridasPublicar víaSuscribirse a travésPeriodo de reproducciónEstructura de cargaLímites de carga
MuleSoftMuleSoft Anypoint Apache Kafka ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector Salesforce Pub/SubCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Plataforma SalesforceApache Kafka on HerokuCódigo proAPI, registrar cambios en Postgres de HerokuN/A1-6 semanasUsuario definidoUsuario definido
Captura de datosCódigo bajo a código profesionalCambios de registroApex, API, componentes web Lightning (LWC)3 díasPredefinido1 MB
Eventos de plataformaCódigo bajo a código profesionalAPI, Apex, FlujoApex, API, Flow, LWC3 díasUsuario definido1 MB
API Pub/SubCódigo proAPI o API Pub/Sub, flujo ApexAPI Pub/Sub3 díasUsuario definido1 MB
Retransmisiones de eventos*Código bajoEventos de plataforma, Captura de datos de cambiosAPI3 díasUsuario definido1 MB
*Las retransmisiones de eventos solo envían datos a AWS Eventbridge
### Transmisión Algunos productores generan una transmisión continua de eventos. Un ejemplo común es la transmisión de medios, que implica interacciones de usuario que se producen de forma natural como eventos discretos. Múltiples sistemas deben reaccionar al mismo comportamiento de usuario simultáneamente sin bloquear la experiencia de transmisión principal. Considere los eventos para una plataforma de transmisión de música. Estos pueden incluir: - Realizar seguimiento de eventos iniciados/en pausa/omitidos - Escuchar eventos de sesión con marcas de tiempo - Eventos de creación/modificación de listas de reproducción - Eventos de colaboración en redes sociales - Descargar para escuchar sin conexión #### El patrón de transmisión En el patrón Transmisión, los suscriptores acceden a cada transmisión de evento y procesan los eventos en el orden exacto en que se reciben. Se envían copias exclusivas de cada transmisión de mensajes a cada suscriptor, lo que permite entregar contenido específico del suscriptor e identificar qué suscriptores reciben qué transmisiones. Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo del patrón de transmisión que representa una transmisión de eventos que se están publicando. Los suscriptores que están escuchando las transmisiones las reciben y las procesan en consecuencia. #### Herramientas relevantes para el patrón de transmisión
Comportamiento y flujo de eventosConsideraciones sobre la carga
Herramientas disponiblesHabilidades requeridasPublicar víaSuscribirse a travésPeriodo de reproducciónEstructura de cargaLímites de carga
MuleSoftTransmisiones de datos de MuleSoft AnypointCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector Salesforce Pub/SubCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint Apache Kafka ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Plataforma SalesforceApache Kafka on HerokuCódigo proAPI, registrar cambios en Postgres de HerokuN/A1-6 semanasUsuario definidoUsuario definido
API Pub/SubCódigo proAPI o API Pub/Sub, flujo ApexAPI Pub/Sub3 díasUsuario definido1 MB
#### Gestión de pedidos de eventos transmitidos Para que una transmisión tenga sentido, todos sus eventos y sus mensajes asociados deben estar en el orden correcto. Si origina los datos en una transmisión desde diferentes sistemas, deberá incorporar lógica de pedido adicional como parte del proceso de diseño. ### Colocación en cola Los casos de uso en cola son omnipresentes. Algunos ejemplos incluyen: - **Conexiones a Internet de baja calidad:** Las organizaciones de servicio de campo u otras organizaciones donde los equipos con dispositivos móviles necesitan trabajar en áreas con acceso a Internet de baja calidad o intermitente se benefician de las colas porque las aplicaciones en estos dispositivos pueden conectarse a sus colas y recuperar cualquier mensaje relevante cuando se restablece la conectividad. - **Almacenamiento en memoria intermedia de mensajes:** Cuando el volumen de mensajes supera ocasionalmente la capacidad de procesamiento de un suscriptor y el aumento de la latencia no crea problemas adicionales, las colas pueden ser un tampón para almacenar mensajes en exceso y evitar la pérdida de datos. - **Gestión de transporte:** Las organizaciones logísticas que necesitan monitorear sus flotas pueden utilizar este patrón para ver las rutas que está realizando cada vehículo casi en tiempo real y garantizar que los conductores son lo más eficientes posible. - **Dispositivos IoT:** Los fabricantes a menudo utilizan sistemas que generan transmisiones rápidas de datos, y estas transmisiones pueden tener efectos descendentes en sistemas adicionales. Este patrón puede utilizarse para identificar secuencias de eventos que requieren intervención humana antes de que se produzcan fallos catastróficos que abarquen múltiples sistemas. #### El patrón de colas En el patrón Colas, los productores envían mensajes a colas, que mantienen los mensajes hasta que los suscriptores los recuperan. La mayoría de las colas de mensajes siguen el orden de llegada y salida (FIFO) y eliminan cada mensaje después de recuperarlo. Cada suscriptor tiene una cola exclusiva, que requiere pasos de configuración adicionales pero permite garantizar la entrega e identificar qué suscriptores recibieron qué mensajes. Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo del patrón de cola que representa un evento que se está publicando y redactando en una cola cuando se modifica un registro. Los suscriptores reciben copias del evento desde sus colas asociadas y realizan las actualizaciones apropiadas en sus propios registros. #### Herramientas relevantes para el patrón de cola
Comportamiento y flujo de eventosConsideraciones sobre la carga
Herramientas disponiblesHabilidades requeridasPublicar víaSuscribirse a travésPeriodo de reproducciónEstructura de cargaLímites de carga
MuleSoftMuleSoft Anypoint MQCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector Salesforce Pub/SubCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint Apache Kafka ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQ ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
MuleSoft Anypoint MQTT ConnectorCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Conector AMQP de Mulsoft AnypointCódigo proAPIAPIComo está configuradoUsuario definidoNinguna
Plataforma SalesforceApache Kafka on HerokuCódigo proAPI, registrar cambios en Postgres de HerokuN/A1-6 semanasUsuario definidoUsuario definido
Captura de datosCódigo bajo a código profesionalCambios de registroApex, API, componentes web Lightning (LWC)3 díasPredefinido1 MB
Eventos de plataformaCódigo bajo a código profesionalAPI, Apex, FlujoApex, API, Flow, LWC3 díasUsuario definido1 MB
API Pub/SubCódigo proAPI o API Pub/Sub, Apex, FlujoAPI Pub/Sub3 díasUsuario definido1 MB
Retransmisiones de eventos*Código bajoEventos de plataforma, Captura de datos de cambiosAPI3 díasUsuario definido1 MB
*Las retransmisiones de eventos solo envían datos a AWS Eventbridge
#### Gestión de memoria y almacenamiento Debido a la naturaleza asíncrona del patrón En cola, puede haber un retraso prolongado entre la incorporación de un mensaje a una cola y la recuperación de ese mensaje. Las colas requieren memoria o espacio de almacenamiento para albergar sus mensajes, de modo que no pueden crecer indefinidamente, lo que significa que un suscriptor que está sin conexión indefinidamente puede provocar un fallo si se acumulan suficientes mensajes en la cola. El almacenamiento en memoria intermedia de mensajes puede tener el mismo efecto si los tiempos de procesamiento de los suscriptores son demasiado largos, lo que provoca que se acumulen grandes volúmenes de mensajes en sus colas. Para mitigar estos riesgos, realice un análisis exhaustivo de los requisitos de almacenamiento para todas las colas de mensajes y, si es necesario, diseñe procesos que purgarán y desactivarán las colas si los mensajes no se recuperan en un tiempo establecido o cuando alcanzan un volumen predeterminado. ## Consideraciones no funcionales Además de las consideraciones funcionales enumeradas en las secciones anteriores, también hay consideraciones no funcionales que deben tenerse en cuenta en su decisión. ### Migración de integraciones de punto a punto Incluso si está completamente convencido de que una arquitectura dirigida por eventos es adecuada para su organización, es posible que esté empezando con un panorama que ya tiene un gran número de integraciones de punto a punto. Obtener financiación para un proyecto para sustituir todas sus integraciones a la vez puede ser difícil, e incluso podría no ser posible utilizar una arquitectura dirigida por eventos directamente con algunos sistemas heredados. En estos escenarios, puede adoptar un enfoque incremental para migrar a una arquitectura acoplada de forma más flexible convirtiendo las aplicaciones más críticas de negocio primero, luego convirtiendo otros sistemas a medida que se actualizan o se sustituyen en proyectos futuros. Este enfoque facilita la tarea de agregar nuevas aplicaciones al bus de eventos y permite que su panorama general de TI se mantenga escalable y resiliente a medida que se siguen agregando sistemas con el tiempo. ### Compensaciones en sistemas poco acoplados Como arquitectos, sabemos que cada arquitectura tiene ventajas. Una arquitectura dirigida por eventos no es una excepción. Aunque un paisaje lleno de sistemas acoplados de forma flexible es altamente ampliable y resistente, también hay algunas ventajas a tener en cuenta: - **Estrategia general de integración:** Independientemente de las herramientas y los patrones que decida utilizar, es importante empezar por crear una estrategia sobre cómo se compartirán los datos entre los diversos sistemas en el panorama de su organización. Esta estrategia debe incluir los objetivos de su organización para sus datos, cómo se pueden compartir los datos y los patrones utilizados, así como orígenes de datos, objetivos, estructuras y requisitos de propiedad y acceso. - **Compatibilidad con sistemas heredados:** Su organización puede tener sistemas heredados que simplemente no admiten patrones de arquitectura dirigidos por eventos. Aunque es posible crear soluciones (por ejemplo, con un proceso que actúa como una transferencia suscribiéndose a eventos y luego enviando el resultado al sistema de destino a través de un medio diferente de transferencia de datos), es posible que desee considerar otros métodos de integración en este caso. - **Cambios estructurales en mensajes:** Una vez definida y acordada la estructura de mensajes inicial entre publicadores y suscriptores, puede ser difícil cambiar, especialmente si los suscriptores son externos. Existen varias formas de solucionar este problema. Puede utilizar extremos versionados, pero asegúrese de definir y comunicar un ciclo de vida claro para cada versión de modo que sus desarrolladores no tengan que mantener demasiadas versiones simultáneamente. Si Apache Kafka en Heroku forma parte de su paisaje, también puede considerar un registro de esquemas o una herramienta similar, pero asegúrese de que los otros sistemas en su paisaje lo admiten (y lo utilizan) también. - **Falta de visibilidad entre publicadores y suscriptores:** En la mayoría de los patrones de arquitectura dirigidos por eventos, los publicadores no conocen el estado de sus suscriptores. Por lo tanto, si un publicador envía un mensaje crítico mientras todos los suscriptores no tienen conexión, es posible que el mensaje nunca se entregue. Puede solucionar este problema haciendo uso de funciones de reproducción o agregando suscriptores redundantes que se ejecutan en servidores separados para todos los mensajes críticos. - **Cuellos de botella de desempeño:** A medida que se amplía una arquitectura dirigida por eventos, el bus de eventos puede convertirse en un cuello de botella para la entrega de mensajes si se ve desbordado por demasiados publicadores que intentan enviar mensajes a demasiados suscriptores de forma simultánea. Puede solucionar esto aumentando la memoria y procesando recursos asignados al bus de eventos o utilizando múltiples buses de eventos para procesar diferentes tipos de mensajes en paralelo. ## Mejores prácticas relacionadas Además de la orientación ya proporcionada, tenga en cuenta las siguientes mejores prácticas. ### Implementación de arquitecturas dirigidas por eventos Antes de implementar una arquitectura dirigida por eventos, considere si realmente necesita utilizar una en primer lugar. La sección anterior describe escenarios de negocio comunes que se ajustan bien a cada patrón de arquitectura dirigido por eventos. También puede leer más en [Bien arquitectado - Fiabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html). Revise los retos a tener en cuenta al implementar arquitecturas dirigidas por eventos para determinar si los patrones que tiene en mente son los más adecuados para sus casos de uso específicos. Tenga en cuenta que aunque la mayoría de los escenarios cubiertos en esta guía implican integraciones, las arquitecturas dirigidas por eventos también se pueden utilizar para enviar mensajes dentro de una única organización de Salesforce a través del uso de eventos de plataforma, por ejemplo. Asegúrese de tener en cuenta cualquier [límite de asignación](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) de eventos aplicable cuando diseñe procesos que utilizan eventos de plataforma como un sistema de mensajería interno. ### Evitar antipatrones Frecuentemente, los antipatrones alrededor de arquitecturas dirigidas por eventos provienen del uso de eventos como una solución para comunicaciones internas en una organización de Salesforce. Los antipatrones comunes incluyen: - **Publicación de eventos desde desencadenadores Apex asociados con el mismo objeto de evento:** Esto dará como resultado un bucle de desencadenador infinito. - **Publicación de eventos desde Apex antes de que se complete una transacción DML:** Si una transacción falla y se revierte, cualquier evento publicado que tenga el comportamiento Publicar inmediatamente no se incluirá en el comportamiento de reversión. - **Publicación de eventos en Flow para orquestar la automatización posterior:** La mejor forma de coordinar la lógica entre múltiples automatizaciones es utilizar [subflujos](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) o [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm). - **Creación de dependencias de tiempo de ejecución:** No publique eventos para facilitar la comunicación entre paquetes sin realizar los [pasos](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) apropiados para eliminar dependencias de tiempo de ejecución. - **Cargas innecesariamente grandes:** Al realizar solicitudes, es mejor enviar y recibir la menor cantidad de datos posible en la carga. Cada acción de un usuario podría generar múltiples solicitudes, y es importante que se procesen de forma eficiente. El envío de más datos de los necesarios puede contribuir a ralentizar el transporte y aumentar el tiempo de procesamiento. - **Gestión no selectiva de eventos de aplicación:** Cuando hay múltiples componentes escuchando un evento de aplicación, los desarrolladores deben asegurarse de que el controlador de eventos solo se ejecutará cuando sea realmente deseado y útil. Por ejemplo, en Lightning Console, los componentes contenidos en fichas que no están enfocadas pueden seguir escuchando aunque no sean visibles. Un desarrollador puede utilizar varias técnicas como el uso de un elemento de utilidad en segundo plano como el único oyente, o llamar a getEnclosingTabId() para determinar si esta instancia del componente está encerrada dentro de la ficha enfocada para garantizar que cada evento se gestiona solo cuando está pensado. - **El uso de Eventos de plataforma publica un comportamiento incorrecto:** Los eventos de plataforma tienen dos comportamientos de publicación: Publicar inmediatamente y Publicar después de confirmar. Puede ser útil utilizar eventos de plataforma en tiempo real para casos de uso como Registro, donde desea publicar el evento de registro independientemente de si la transacción se realiza correctamente y se confirma. Sin embargo, utilice Publicar inmediatamente con mucho cuidado con eventos de plataforma en tiempo real. Los suscriptores pueden consumir eventos en la misma transacción y provocar bloqueos de filas u otras condiciones de carrera. ### Diseño de eventos efectivos Al implementar una arquitectura dirigida por eventos, una de las claves del éxito es establecer estándares para el diseño de los eventos en sí. Las especificaciones variarán dependiendo de los casos de uso de su organización, pero estas son algunas directrices generales: - **Determine la estructura óptima para sus cargas de eventos.** Aunque los tamaños de mensajes más pequeños reducen los tiempos de procesamiento, el bombardeo de suscriptores con volúmenes masivos de mensajes puede causar cuellos de botella de desempeño. Es posible que tenga que iterar en sus tamaños y estructuras de carga para encontrar el equilibrio correcto. MuleSoft y herramientas ESB similares proporcionan la capacidad de diseñar cargas personalizadas en los mensajes asociados con sus eventos, lo que puede ayudarle a visualizar estructuras de datos para mejorar el desempeño en el lado del suscriptor. (Consulte [Bien arquitectado - Fiabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html) para obtener más información.) - **Piense en sus procesos de extremo a extremo.** Asegúrese de no crear ningún escenario de "bucle infinito", que puede ser difícil de rastrear una vez que se implementen las integraciones. Un ejemplo de esto serían dos sistemas que publican eventos cuando se actualizan registros, mientras también escuchan los eventos del otro, lo que desencadena eventos publicados adicionales cuando se procesan. Puede solucionar este tipo de antipatrón agregando lógica a ambos sistemas que garantiza que los cambios realizados como resultado de un evento que se está consumiendo no dan como resultado la publicación de un nuevo evento. También debe asegurarse de documentar todos sus eventos, sus desencadenadores asociados y los sistemas descendentes que pueden verse afectados. Utilice esta documentación como referencia durante sesiones de diseño para ayudar a captar bucles interminables y escenarios similares lo antes posible. (Consulte [Well-Architected - Operational Excellence](/docs/architect/es-mx/well-architected/guide/operational-excellence.html) para obtener más información.) - **Utilice convenciones de nomenclatura comunes entre sistemas.** Las convenciones de nomenclatura coherentes son una mejor práctica para todo el desarrollo de software, incluyendo arquitecturas dirigidas por eventos. Tómese su tiempo para documentar un conjunto de estándares para nombres de eventos, estructuras, objetos asociados y procesos de gestión de errores para garantizar la coherencia entre sistemas. (Consulte [Bien arquitectado - Excelencia operativa](/docs/architect/es-mx/well-architected/guide/operational-excellence.html) para obtener más información.) ## Recursos
PatrónRecursos
Publicar/SuscribirSalesforce Well-Architected: fiabilidad
Salesforce Well-Architected - Excelencia operativa
Publicación de blog: Alcanzar eficiencia arquitectónica con retransmisiones de eventos
Publicación de blog: Anuncio de API Pub/Sub disponible de forma general
Publicación de blog: Paso de RESTful a EVENTful
Publicación de blog: Arquitecturas dirigidas por eventos y la especificación AsyncAPI
Video: Publicar / Suscribir presentación de patrón
FanoutPublicación de blog: Cómo trabajar dentro de los límites de entrega de eventos de plataforma
Video: Presentación de patrón de Fanout
Mensajes pasadosVideo: Presentación de patrón de mensajes pasados
TransmisiónPublicación de blog: Diseño para escrituras de gran volumen en Salesforce
Video: Presentación de patrón de transmisión
Documentación: Transmisión en aplicaciones Mule
Colocación en colaPublicación de blog: Diseño para escrituras de gran volumen en Salesforce
Publicación de blog: Cómo diseñar arquitecturas de pago con API con eventos
Video: Presentación de patrón de cola
# Automatización desencadenada por registro Salesforce Platform ha avanzado continuamente en su arquitectura de automatización para satisfacer las demandas de procesos de negocio complejos. Las generaciones anteriores (Reglas de flujo de trabajo y Process Builder) proporcionaban los pasos iniciales en la lógica dirigida por eventos, ampliando las funciones de automatización para la lógica dirigida por eventos y ampliando el alcance a una gama más amplia de generadores. Esta evolución ha culminado en una arquitectura consolidada de alto rendimiento centrada en dos pilares complementarios: Flujo desencadenado por registro y Desencadenadores de Apex. ## Descripción general de guía Este documento proporciona el marco y las directrices para tomar decisiones fundamentadas al diseñar automatizaciones de desencadenadores. Equilibra los requisitos de casos de uso con tres puntos de decisión principales que le guiarán a elegir el enfoque correcto para la automatización desencadenada por cambios en registros de Salesforce. ## Productos en ámbito
Flujo Salesforce Flow es una potente herramienta de automatización de apuntar y hacer clic que permite a los usuarios crear procesos de negocio complejos, pantallas y lógica visualmente utilizando Flow Builder, sin redactar código. Automatiza tareas como actualizaciones de datos, envío de emails y orientación de usuarios, ofreciendo flexibilidad a través de tipos como Flujos de pantalla (interacción de usuario) y Flujos desencadenados (eventos de registro/programados).
Apex Salesforce Apex es un lenguaje de programación patentado y orientado a objetos para la plataforma Salesforce, similar a Java, que se utiliza para crear lógica de negocio personalizada, automatizar procesos y ampliar las funciones principales de CRM más allá de las herramientas declarativas.
## Comida para llevar La creación de automatizaciones desencadenadas por registros ampliables, mantenibles y con desempeño en Salesforce Platform requiere un enfoque disciplinado dirigido por la arquitectura. La elección entre Flow y Apex, y la implementación de cada uno, se guía por un conjunto claro de principios. Estos puntos resumen estos principios y sirven como reglas fundamentales para el diseño de automatización moderno. - **Seleccione la herramienta correcta para el trabajo en base a la densidad de automatización de objetos de Salesforce.** - Utilice Flujo desencadenado por registro para objetos de Salesforce para automatizaciones de **baja densidad**. - Aumente la lógica de flujo desencadenado por registro con Apex invocable para automatizaciones de **densidad media**. - Utilice desencadenadores Apex para objetos de Salesforce para automatizaciones de **alta densidad**. - **Tenga cuidado al desencadenar procesos asíncronos.** Esta regla se aplica independientemente de que esté invocando procesos asíncronos en un flujo desencadenado por registro o poniendo un trabajo colocable en cola desde Apex. Aunque este patrón puede ser tentador para descargar trabajo, puede introducir escenarios de gestión de errores complejos y aumentar el riesgo de alcanzar límites reguladores. - **Utilice un punto de entrada por objeto de Salesforce.** Para un objeto de Salesforce concreto, utilice un mecanismo como su punto de entrada en la automatización. Trate de evitar mezclar desencadenadores de Flujo y Apex como puntos de entrada para el mismo Objeto. ## Puntos de decisión Existen tres puntos de decisión principales a tener en cuenta: - Implementación declarativa frente a programática - Densidad de automatización - Matriz de selección de densidad ### Implementación declarativa frente a programática Flow y Apex comparten un conjunto común de funciones fundamentales. Cada herramienta puede consultar registros, ejecutar lógica condicional, asignar variables y realizar operaciones DML como la creación, actualización y eliminación de registros, secuenciados para ejecutarse en un orden especificado. Sin embargo, este solapamiento funcional no implica que las herramientas sean intercambiables. La elección arquitectónica no se trata de _si_ se puede realizar una tarea, sino de _cómo_ se realiza y cuáles son las implicaciones a largo plazo para el desempeño, la capacidad de ampliación y la capacidad de mantenimiento. Flujo destaca en claridad declarativa y velocidad de implementación para procesos sencillos, mientras Apex proporciona el control granular y la potencia bruta necesaria para soluciones complejas. ### Densidad de automatización La **densidad de automatización** es la carga aplicada a un objeto específico de Salesforce. Sirve como una heurística para determinar la implementación óptima del objeto. A medida que crece la densidad de automatización, aumenta la probabilidad de infringir límites de transacciones. Calcule la densidad de automatización inspeccionando tres dimensiones específicas de volumen y complejidad: - **Cantidad de automatización:** El número sin procesar de entradas de metadatos de automatización exclusivas (flujos, acciones de desencadenador, etc.) que se ejecutan durante un único evento de Lenguaje de manipulación de datos (DML). - **Volumen de registro:** Los registros por transacción procesados a través de cargas de API o procesamiento por lotes intenso, donde el desempeño se vuelve crítico. - **Extensión de dependencia:** Una medición de las operaciones DML descendentes desencadenadas por la operación CRUD inicial. Cuantifica la profundidad del gráfico donde una actualización entra en cascada en actualizaciones en objetos relacionados (por ejemplo, caso → cuenta → contacto → acumulación personalizada). Dimensiones de densidad de automatización A medida que crece el ámbito y la complejidad de su aplicación de Salesforce, confirme un único punto de entrada principal: Flujo desencadenado por registro o Desencadenadores de Apex. Evite particionar automatizaciones entre múltiples mecanismos en un único objeto de Salesforce, ya que lleva a una mala capacidad de mantenimiento y una gobernanza fragmentada. ### Matriz de selección de densidad Utilice esta matriz para determinar el estándar arquitectónico requerido para su objeto de Salesforce. - **Flujo desencadenado por registro** es la solución preferida para baja densidad de automatización. Ofrece un equilibrio de potencia y accesibilidad ideal para automatizaciones sencillas e independientes entre sí. - **El patrón híbrido (Flujo desencadenado por registro con Apex invocable)** es una opción potente y mantenible para automatizaciones de densidad media con complejidad creciente. Este patrón permite a los equipos mantener la coreografía ordenada en Flujo declarativo mientras delegan operaciones con gran volumen de computación en Apex, equilibrando la accesibilidad con el desempeño. - Los **desencadenadores Apex** proporcionan los elementos constructivos necesarios para una base arquitectónica sólida que admita automatizaciones de alta densidad. El desempeño, el control granular y la abstracción y el polimorfismo orientados a objetos de Apex son más adecuados para gestionar la complejidad y la escala de estos escenarios.
Nivel de densidad Cantidad de automatización Volumen de datos (Tamaño de lote) Extensión de dependencia Estándar arquitectónico
Bajo < 15
Automatizaciones
Estándar
Interacciones de la interfaz de usuario dirigidas por el usuario o pequeñas cargas de API (1 a 200 registros)
Discreta
Lógica autónoma. 0-1 operaciones DML descendentes en el mismo objeto o un objeto relacionado.
Flujo desencadenado por registro
Medio 15–30
Automatizaciones
Moderado
Procesamiento por lotes estándar (con lógica que requiere una masificación cuidadosa)
Acoplado
Principal/Secundario actualiza de 2 a 4 operaciones DML descendentes. Riesgo de recurrencia
Patrón híbrido
Flujo + Apex invocable
Alto > 30
Automatizaciones
Alto
Grandes volúmenes de datos con cargas de API masivas (2.000 a 10.000+ registros)
Complejo y recursivo
Gráfico de dependencia profunda (5+ operaciones DML descendentes). Riesgo de bucles de recursión triangulares
Marco de metadatos desencadenado por Apex
Las decisiones arquitectónicas del mundo real requieren que sopese todas las dimensiones de la densidad de automatización de forma colectiva. Tenga en cuenta el posible ámbito futuro al seleccionar un mecanismo de automatización para un objeto de Salesforce concreto. Además, tenga en cuenta el número total diario de operaciones DML porque Salesforce aplica la gestión de recursos compartidos en un entorno de múltiples arrendatarios y [limita](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) para evitar que las automatizaciones descontroladas monopolicen recursos compartidos. Los objetos de Salesforce con un gran volumen DML diario requieren una cuidadosa selección de automatización. Por ejemplo, los límites asíncronos de tiempo de CPU (60.000 ms) y tamaño de pila (12 MB) son superiores a los límites síncronos. Además, el límite de 24 horas de toda la organización en ejecuciones asíncronas (calculado como 250.000 o 200 veces sus licencias de usuario) requiere tener en cuenta el DML diario total en su diseño arquitectónico para evitar excepciones en tiempo de ejecución. ## Comparación de productos Flujo desencadenado por registro es la principal herramienta declarativa de la plataforma para la automatización desencadenada por registro. La facilidad de uso de Flow y las salvaguardas de plataforma integradas permiten a los equipos crear fácilmente soluciones escalables y fiables. Es la opción ideal para la mayoría de equipos que crean soluciones en Salesforce Platform. Apex es el lenguaje de programación patentado, fuertemente tipificado y orientado a objetos de la plataforma. Utilice Apex para objetos de Salesforce con alta densidad de automatización y para casos de uso que requieren alto desempeño, lógica sofisticada o control granular sobre transacciones. Para ayudar en el proceso de toma de decisiones, esta matriz proporciona una comparación directa de Flujo y Apex entre funciones arquitectónicas clave.
Capacidad Flujo desencadenado por registro Desencadenador Apex
Rápida entrega y mantenimiento Recomendado
La interfaz de usuario visual de Flow Builder permite a los administradores y otros generadores declarativos crear y modificar automatizaciones con mayor rapidez que redactar, probar e implementar código Apex. Esta interfaz potencia una gama más amplia de miembros del equipo para entregar valor de negocio y reduce la dependencia de recursos de desarrollador especializados para tareas sencillas.
Requiere experiencia
Apex requiere desarrolladores de software debidamente cualificados para implementar, probar y mantener el código.
Modularidad Disponible
Los flujos desencadenados por registros son modulares de forma predeterminada. En vez de lógica monolítica, los equipos crean flujos discretos para requisitos específicos y los coreografíen juntos utilizando el Explorador de desencadenadores de flujos. Esta modularidad permite una modificación aislada y una ampliación sencilla, reduciendo enormemente el costo de propiedad a largo plazo.
Disponible
Apex está dividido en módulos funcionales por diseño. Cada clase Apex está pensada para implementar un único módulo de funciones.
Visibilidad y gobernanza Recomendado
La naturaleza visual de Flujo proporciona una representación intuitiva de la lógica de negocio. El Explorador de desencadenadores de flujos proporciona una vista consolidada de todos los flujos en un objeto, facilitando a los arquitectos y administradores la tarea de comprender, gobernar y solucionar problemas sin leer código.
Requiere experiencia
El uso de un marco de trabajo de metadatos para organizar desencadenadores es ventajoso, pero Apex requiere un equipo de desarrollo disciplinado para mantener el código organizado y mantenible.
Procesamiento masivo de datos de alto desempeño No recomendado
Existe un riesgo elevado de alcanzar límites reguladores cuando se trata de lógica compleja o grandes volúmenes de datos.
Recomendado
El código Apex se ejecuta más cerca de los servicios principales de la plataforma y ofrece a los desarrolladores un control mejorado sobre la optimización de consultas, el tratamiento de datos y la eficiencia algorítmica. Esto da como resultado un mejor desempeño y escala, especialmente en escenarios complejos que implican grandes volúmenes de datos.
Lógica robusta y estructuras de datos Disponible
El elemento Transformación de flujo puede ayudar con algunas tareas de procesamiento complejas. Sin embargo, Flow carece de estructuras de datos de asignación y conjunto nativas, lo que hace que el procesamiento de datos complejo sea engorroso e ineficiente desde el punto de vista computacional.
Recomendado
Apex proporciona acceso completo a Map, Set y bucles programáticos para una manipulación de datos altamente eficiente y segura. Como un lenguaje de programación completo, Apex también proporciona acceso a construcciones lógicas complejas, estructuras de datos y patrones de diseño que pueden ayudar a resolver problemas de negocio complejos de una manera mantenible y eficiente. Apex incluye una biblioteca estándar enriquecida de funciones avanzadas (por ejemplo, BusinessHours, Crypto) no disponible actualmente en herramientas declarativas.
Control de transacciones No disponible
Flow no proporciona acceso a `Database.savepoint`, `Database.rollback` u operaciones DML parcialmente satisfactorias para confirmaciones o reversiones de transacciones parciales.
Disponible
Apex proporciona un control completo y granular sobre la integridad de las transacciones y escenarios de recuperación de errores complejos.
Distribución de email Recomendado
El envío de alertas de email preconfiguradas desde un flujo desencadenado por registro es sencillo y ampliable. Las alertas de email personalizadas se pueden crear y distribuir en tiempo de ejecución. Los emails personalizados están sujetos a límites de envío diarios.
Disponible
Apex puede generar y enviar mensajes de email personalizados. Todos los emails enviados desde Apex están sujetos a los límites de envío diarios.
Aplicación de salvaguardias de plataforma Recomendado
El flujo incluye protecciones integradas, como la masificación automática y los reintentos automáticos. Estas salvaguardas aumentan la velocidad de valorización y evitan riesgos de desempeño que requieren codificación manual compleja.
Se requiere implementación manual
Las salvaguardias como el masificado deben codificarse de forma explícita (por ejemplo, gestionando recopilaciones y evitando SOQL dentro de bucles). Los reintentos automáticos no son nativos de desencadenadores y requieren lógica personalizada compleja para implementarse.
Procesamiento asíncrono Disponible
Flow ofrece mecanismos sencillos para automatizaciones que requieren una transacción separada en una ruta asíncrona. Estas automatizaciones están sujetas a límites diarios.
Disponible
Apex permite el control completo mediante Captura de datos de cambios y eventos colocables en cola gestionados por un suscriptor de desencadenador desvinculado.
Procesamiento programado Recomendado
Las rutas programadas del flujo proporcionan una capacidad de programación única y potente (por ejemplo, "disparo 3 días antes de la fecha de cierre"). Esta función incluye la cancelación automática y la reprogramación si cambian los datos del registro. Estas automatizaciones están sujetas a límites diarios.
No disponible
Un desencadenador Apex no puede programar de forma nativa un evento específico de registro temporal con cancelación automática. Aunque Apex programado existe, es un mecanismo fundamentalmente diferente que se ejecuta a una hora específica y no se programa durante el procesamiento de un registro individual como parte de un desencadenador.
Ordenación y coreografía Disponible
El Explorador de desencadenadores de flujos permite a los administradores definir un orden de ejecución relativo para múltiples flujos en el mismo objeto.
Disponible
Un marco de trabajo de desencadenador proporciona control granular sobre el orden exacto de las automatizaciones.
Actualizaciones de campos del mismo registro Disponible (antes de guardar)
Flujo desencadenado por registro es la opción declarativa de mayor desempeño para actualizar el registro desencadenante antes de la confirmación DML inicial.
Disponible (antes de guardar)
Apex proporciona la oferta de mayor desempeño con un gasto general mínimo.
Crudo de objeto cruzado Disponible (después de guardar)
Flujo es adecuado para operaciones DML de objetos cruzados sencillas y de baja complejidad.
Disponible (después de guardar)
Apex proporciona un control superior sobre la deduplicación, la gestión de errores y el desempeño para operaciones DML de objetos cruzados.
Deduplicación de cálculos costosos Disponible
Flujo destaca en la eliminación de consultas redundantes y declaraciones DML a través de masificación automática. Sin embargo, el estado no se puede almacenar en caché o compartir entre diferentes desencadenadores de flujo o entre múltiples invocaciones del mismo flujo en una transacción. Esta limitación puede volverse importante en escenarios de desempeño extremo.
Recomendado
Apex proporciona mecanismos para deduplicar operaciones costosas. Los desarrolladores pueden aprovechar el almacenamiento en caché de transacciones utilizando variables y propiedades estáticas, y el almacenamiento en caché a nivel de plataforma utilizando Caché de plataforma, para almacenar y reutilizar datos. Estas técnicas son importantes para reducir el consumo de límites reguladores de transacciones, como consultas SOQL, y garantizar un alto desempeño y capacidad de ampliación.
Gestión de errores personalizados Disponible
El elemento CustomError puede bloquear una operación de guardado y mostrar un mensaje al usuario.
Recomendado
El método addError() proporciona mensajería de error condicional y a nivel de campo flexible.
## Casos de uso Para enfatizar mejor cómo utilizar los puntos de decisión para guiar sus decisiones, considere los siguientes casos de uso y puntos de análisis asociados. ### Recomendaciones más ajustadas Esta tabla proporciona recomendaciones generales "mejor ajustadas" para casos de uso generales, basándose en las funciones presentadas. En última instancia, tendrá en cuenta consideraciones adicionales para llegar a un mejor ajuste para sus escenarios particulares, como aquellos incluidos en la sección _Mejores prácticas relacionadas_ de este documento. Allí, aprenderá más sobre cuándo una combinación concreta de Flow y Apex proporciona el mejor enfoque.
Caso de uso Descripción Mejor ajuste Justificación
Procesamiento por lotes de alto desempeño Cualquier automatización que debe procesar miles de registros de forma eficiente Apex Apex proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.
Procesamiento de datos complejo Escenarios que requieren manipulación de datos avanzada Apex Apex proporciona estructuras de datos, como Map y Set, que no están disponibles de forma nativa en Flow, y pueden ser críticas para redactar código de desempeño seguro y masivo.
Control de transacciones Mecanismos de control como puntos de guardado, reversiones y confirmaciones parciales Apex Apex proporciona acceso a mecanismos como Database.savepoint y Database.rollback, y tiene la capacidad de procesar operaciones DML parcialmente satisfactorias.
Sofisticada validación personalizada Validación de datos entre múltiples campos en un registro Apex Aunque Flujo puede evitar un guardado con el elemento `CustomError`, no está disponible en todos los tipos de flujo, incluyendo subflujos. El método Apex addError() proporciona múltiples mensajes de error específicos de campo que se pueden agregar a un registro en cualquier momento durante el procesamiento del desencadenador.
Lógica moderadamente compleja en un proceso sencillo Manipulación de lógica y datos de complejidad moderada, simplificada por una biblioteca estándar de funciones avanzadas, que se produce como parte de un proceso sin complicaciones Flujo + Apex Flujo desencadenado por registro actúa como la capa de orquestación, mientras que las operaciones de alta complejidad están encapsuladas en Apex invocable.
Lógica simple a moderadamente compleja Manipulación de datos de complejidad baja a moderada, con actualizaciones de desencadenador en los objetos de datos principales y relacionados Flujo Flujo es normalmente la opción a la que dirigirse, ya que se basa en un modelo declarativo que lo hace accesible tanto para administradores como desarrolladores.
Notificaciones y mensajes salientes Envío de emails y mensajes salientes Flujo Flujo hace que el envío de alertas de email y mensajes salientes en cambios de registro sea sencillo y altamente escalable.
Procesamiento programado Automatización en una fecha futura dinámica (por ejemplo, 3 días antes de una fecha de cierre) Flujo Las rutas programadas proporcionan una solidez única a Flujo, ya que la plataforma gestiona automáticamente la programación, cancelación y reprogramación de estas rutas si cambian los datos del registro.
### Procesamiento ampliable: Casos de uso asíncronos en profundidad La capacidad de ampliación es una consideración crítica al diseñar su implementación. Cuando la lógica de negocio de una automatización desencadenada por registro se vuelve compleja, de larga ejecución o implica altos volúmenes de datos, los límites reguladores principales de la plataforma Salesforce se convierten en una restricción arquitectónica. Las operaciones como actualizaciones de datos masivas, llamadas de API complejas o cálculos pesados aumentan el riesgo de infringir límites, como el tiempo total de CPU o el número de declaraciones DML en una sola transacción de base de datos. Un fallo en un desencadenador síncrono debido a una excepción de límite hará que se revierta toda la transacción de guardado del usuario, dando como resultado una mala experiencia del usuario y una posible pérdida de datos. Este riesgo inherente exige un patrón arquitectónico para descargar trabajo complejo. La automatización asíncrona se vuelve esencial en este caso. Utilizando mecanismos asíncronos, los arquitectos pueden desvincular de forma efectiva el trabajo de larga duración o gran volumen de la transacción de guardado de registros síncrona principal. Guarda completo de forma rápida y fiable, mientras que el procesamiento pesado se delega a una transacción gestionada por plataforma separada que se ejecuta más adelante. La desvinculación mejora la estabilidad, evita fallos de transacciones y es clave para crear aplicaciones de negocio ampliables. La plataforma ofrece varias herramientas especializadas para esto, cada una con distintos beneficios y ventajas en cuanto a fiabilidad, volumen y complejidad. ### Ruta asíncrona del flujo La ruta Ejecutar de forma asíncrona en un flujo desencadenado por registro proporciona el mecanismo más sencillo para la lógica asíncrona "disparar y olvidar". Esta ruta se ejecuta en una transacción separada después de que la transacción de guardado de registros original se haya confirmado correctamente en la base de datos. - **Caso de uso ideal**: Esto es adecuado para tareas que no requieren ejecución inmediata o tratamiento de errores personalizado. Algunos ejemplos incluyen el envío de una notificación por email, la creación de una tarea de seguimiento o la realización de una llamada sencilla a un sistema externo. - **Limitaciones**: Este mecanismo comparte los mismos límites reguladores diarios que otras entrevistas de flujo asíncronas. No está diseñado para un procesamiento de gran volumen. ### Captura de datos de cambios (CDC) Captura de datos de cambios (CDC) es un patrón de alto rendimiento, ampliable y resistente para gestionar lógica asíncrona desencadenada por un cambio de registro en escenarios de gran volumen. En este modelo, la única responsabilidad del desencadenador es guardar el registro de forma síncrona. A continuación, la plataforma publica un mensaje de evento detallado que contiene los cambios del registro en un bus de eventos de gran volumen. Un desencadenador Apex separado y exclusivo se suscribe a este evento de cambio. Realiza trabajos complejos, de larga duración o asíncronos. - **Beneficio**: Este patrón desvincula el proceso asíncrono de la transacción de usuario inicial. Un fallo en el procesamiento asíncrono no provocará la reversión del guardado de registros del usuario. El patrón también proporciona una transmisión de eventos duradera que múltiples suscriptores internos o sistemas externos pueden consumir, y los eventos pueden reproducirse durante hasta 72 horas, proporcionando una fuerte resistencia. - **Limitaciones**: Los mensajes de eventos de CDC no contienen el estado anterior del registro, el equivalente de un `Trigger.oldMap` Apex. La carga de evento incluye los nuevos valores de campo, pero no los valores desde los que cambiaron. Esto dificulta la implementación de lógica basada en una transición de estado específica (por ejemplo, ejecutar solo si `Status__c` cambió de "Pendiente" a "Aprobado"). Puede mitigar esto consultando el historial de campos del objeto en el suscriptor del evento, pero esto agrega complejidad al proceso y el seguimiento del historial de campos podría no estar disponible para el campo de interés específico. Esto puede limitar los tipos de automatización que puede descargar en los CDC. De forma predeterminada, CDC se puede activar en un máximo de cinco objetos de Salesforce. Las organizaciones que requieren más pueden adquirir una licencia complementaria que elimina este límite y aumenta las asignaciones de entrega de eventos. ### Apex colocable en cola desde un desencadenador Colocar un trabajo de Apex en cola directamente desde un desencadenador debe considerarse un patrón de riesgo, utilizado solo cuando se necesita el control proporcionado por Apex (por ejemplo, para lógica compleja o mecanismos de reintento personalizados), y CDC no es una opción viable. Si se requiere Apex colocable en cola, la implementación debe incluir las salvaguardas apropiadas: - **Limitar comprobaciones**: El código debe comprobar el número de trabajos ya en cola en la transacción antes de intentar agregar otro. ``` if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... } ``` - **Conciencia del contexto**: El código debe detectar si se está ejecutando en un contexto asíncrono, como un trabajo por lotes (`System.isBatch()`), y modificar su comportamiento para cumplir el límite más estricto de un trabajo por transacción en ese contexto. ### Limitar consideraciones para Apex asíncrono desencadenado Invocar Apex asíncrono desde un desencadenador síncrono introduce riesgos de estabilidad. Para evitar la repercusión a nivel de organización (por ejemplo, superar límites), este patrón requiere un diseño y pruebas rigurosos. - El límite diario para ejecuciones asíncronas de Apex (`Batch`, `Queueable`, `@Future`) se comparte en toda la organización (normalmente 250.000 o un cálculo basado en licencias de usuario). Una carga de datos masiva de 20.000 registros hará que se ejecute un desencadenador en partes de 200, dando como resultado 100 invocaciones de desencadenador separadas, incluso más si el tamaño de lote masivo es inferior a 200 registros. Si cada invocación pone en cola un trabajo asíncrono, se puede consumir una parte significativa del límite diario de una única carga de datos. Este consumo puede privar potencialmente a otros procesos de negocio críticos de recursos asíncronos. - Los límites reguladores para los trabajos en cola son drásticamente diferentes dependiendo del contexto. Desde un desencadenador activado por una acción de usuario en la interfaz de usuario (una transacción _síncrona_), se pueden poner en cola hasta 50 trabajos colocables en cola. Sin embargo, desde un desencadenador activado dentro del método `execute` de una clase Apex por lotes (una transacción _asíncrona_), solo se puede poner en cola un trabajo colocable en cola. No tener en cuenta esta diferencia es un punto de fallo común y crítico, que lleva a errores de `LimitException` durante operaciones de datos de gran tamaño. - Llamar Apex programable (`System.schedule`) o Apex por lotes (`Database.executeBatch`) directamente desde un contexto de desencadenador constituye un antipatrón. Estos métodos no están diseñados para invocarse desde contexto de desencadenador. Al hacerlo se producirá un consumo rápido de su asignación de Apex asíncrona, lo que dará como resultado excepciones de límite. ### Selección del patrón asíncrono correcto Cada mecanismo asíncrono tiene ventajas específicas en cuanto al desempeño, los límites reguladores y la fiabilidad. Utilice este árbol de decisiones como guía para ayudarle a navegar por estas opciones y elegir el mecanismo correcto para su caso de uso. Árbol de decisiones de patrón asíncrono ### La alternativa de trabajo programado Como indica el gráfico de flujo, cuando se enfrenta a operaciones DML de gran volumen pero no puede utilizar Captura de datos de cambios (quizás debido a límites de objetos), la mejor opción arquitectónica es a menudo evitar un proceso invocado por desencadenador completamente. En su lugar, considere utilizar un proceso programado. Este puede ser un Flujo programado o Apex programado. Los pasos requeridos son: 1. Realice una actualización sencilla y de bajo costo en el desencadenador síncrono. Por ejemplo, establezca un campo de `Status__c` en "procesamiento pendiente" o inserte un registro relacionado de bajo costo, como una publicación de Chatter, para indicar que el registro necesita procesamiento. 2. Cree un trabajo programado, ya sea un flujo programado o Apex programado, que se ejecuta periódicamente, como cada 15 minutos o cada hora. 3. Tenga la consulta de trabajo programada para todos los registros en el estado pendiente, ejecute la lógica compleja en un contexto controlado de gran volumen y luego actualice los registros como procesados. Este patrón desvincula completamente el procesamiento pesado del guardado síncrono del usuario, no está sujeto al límite de un trabajo por transacción de un lote desencadenado y proporciona una solución altamente ampliable y gobernable para requisitos que no son en tiempo real. Si la latencia de un trabajo programado no es aceptable para los requisitos de negocio y aún está restringido a utilizar CDC o una cola desencadenada, esto indica un desajuste arquitectónico significativo. En este punto, deben considerarse diferentes mecanismos. La reevaluación del diseño de la aplicación principal puede llevar a ciertas conclusiones, como: - Adquisición del complemento para eliminar límites de objetos de CDC. - Fundamentalmente, desafiar el requisito de negocio para determinar si el procesamiento casi en tiempo real es realmente una necesidad o si la latencia de un trabajo programado es una ventaja aceptable para la estabilidad de la plataforma. ## Consideraciones no funcionales Además de los puntos de decisión, deberá tener en cuenta consideraciones no funcionales como la complejidad y los estándares. ### Complejidad El nivel de complejidad en una implementación forma parte del costo total de propiedad de una solución, así como su capacidad de adaptarse a los requisitos de negocio cambiantes. La complejidad puede afectar a cualquier implementación si no se siguen las mejores prácticas. En la sección _Mejores prácticas relacionadas_ de este documento, existen recomendaciones para reducir la cantidad de complejidad en su solución, incluyendo estos patrones: - Patrón híbrido: Apex invocable para lógica compleja en flujo - Uso de un marco de trabajo de metadatos para desencadenadores Apex - Megaflujos frente a múltiples flujos ### Procesos y estándares La documentación es tan importante como la automatización en sí. No solo garantiza la capacidad de mantenimiento, también es clave para la IA y las herramientas basadas en agentes. La documentación le ayuda a comprender y gestionar sus procesos de negocio. **En flujo** - Establezca una convención de nomenclatura coherente para todos los elementos y variables. - Utilice el campo Descripción para el flujo para explicar su propósito general, criterios de desencadenador y resultado previsto. - Utilice el campo Descripción en cada elemento individual (por ejemplo, `Get Records`, `Action`, `Transform`). Esta práctica es la mejor forma de transmitir la intención. Es especialmente importante para acciones y subflujos invocables, donde la descripción es el lugar principal para explicar la lógica compleja realizada por la acción. **En Apex** - Comente su código claramente para explicar el _por qué_ detrás de su lógica, no solo el _qué_. - Si utiliza un marco de trabajo dirigido por metadatos, asegúrese de que sus registros de metadatos incluyen y rellenan un campo Descripción legible para explicar qué hace cada clase de controlador y cuándo debe ejecutarse. DevOps y el control de origen forman parte de un ciclo de vida de desarrollo maduro. Utilice siempre una herramienta de control de origen como Git para proyectos de Salesforce. Tanto las clases Apex como Salesforce Flows son metadatos que definen su lógica de negocio, y deben versionarse y gestionarse. En el contexto de la gestión de automatizaciones desencadenadas por registros, una canalización de DevOps moderna proporciona beneficios esenciales. - **Comprobaciones de calidad automatizadas:** Herramientas como [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) se pueden configurar para ejecutarse automáticamente en sus oportunidades en curso. El análisis estático puede detectar patrones problemáticos en ambas herramientas de automatización antes de promocionarse, marcando problemas como elementos de `Get Records` ineficientes dentro de un bucle de flujo o consultas de `SOQL` dentro de un bucle de Apex for, que son causas comunes de degradación del desempeño. - **Prevención de regresión:** A medida que crece su densidad de automatización, un cambio en una clase de Flujo o Apex puede tener consecuencias no deseadas para otras automatizaciones en el mismo objeto. Una estrategia de pruebas de DevOps sólida, donde las pruebas de Apex automatizadas se ejecutan contra cualquier cambio propuesto, es la forma más fiable de garantizar que una nueva versión de Flow no rompe la lógica Apex existente (y viceversa). - **Colaboración y visibilidad:** El control de origen es la "fuente única de verdad". Permite a los administradores y desarrolladores trabajar en la automatización para el mismo objeto en paralelo. También proporciona un seguimiento de auditoría inestimable: cuando se interrumpe un proceso de producción, puede ver al instante _quién_ cambió la automatización, _cuándo_ la cambió y, a través de mensajes de confirmación, _por qué_ la cambió. Para equipos con una combinación de administradores y desarrolladores, [DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) proporciona una interfaz unificada para ayudar a coreografiar todos estos pasos, haciendo accesible un proceso de desarrollo escalable basado en el control de origen para todos los miembros del equipo. Esta disciplina combinada de documentación y DevOps garantiza el estado y la capacidad de mantenimiento a largo plazo de su organización, lo que beneficiará a cada arquitecto y administrador que le siga. ## Mejores prácticas relacionadas La guía de decisiones anterior se utiliza mejor antes de planificar su implementación. Está dirigido a ayudarle a elegir el mejor producto para sus casos de uso. Tras la selección del producto, es importante comprender las mejores prácticas existentes para su implementación. ### Explotar el patrón híbrido: Apex invocable para lógica compleja en flujo El principio _Una herramienta por objeto_ es crítico para gestionar la automatización de alta densidad, pero no lo interprete como una opción binaria entre una pila puramente declarativa o programática. Un patrón arquitectónico más efectivo y mantenible aprovecha un modelo híbrido: posicione Flujo desencadenado por registro como la capa de orquestación, mientras encapsula operaciones de alta complejidad dentro de Apex invocable. Diagrama de patrón híbrido #### La capa de orquestación: Flujo Flujo desencadenado por registro sirve como la capa de orquestación para el proceso de negocio. Posee los criterios de entrada y el contexto de ejecución (el _qué_ y _el cuándo_). Al mantener la lógica de decisiones y el enrutamiento en esta capa, la topología de procesos de la arquitectura permanece transparente y gestionable a través del Explorador de desencadenadores de flujos, evitando que la lógica de negocio crítica se oculte en el código. #### El componente Complejo: Apex invocable Un ejemplo común de un componente complejo es la implementación de cálculos de Acuerdo de nivel de servicio (SLA) para registros Caso. Puesto que el objeto BusinessHours y su lógica relacionada (crítica para cálculos precisos que excluyen horarios no laborales y festivos) no es accesible de forma nativa en Flow, se utiliza una clase de Apex dedicada. Esta clase, a menudo denominada algo así como `ServiceLevelAgreementCalculator`, está diseñada con un único método estático, anotado con `@InvocableMethod`, para calcular el horario laboral transcurrido, determinar si el SLA está "Dentro del objetivo" o "Incumplido" y devolver un resultado estructurado. Este enfoque encapsula la lógica compleja y de alto desempeño en Apex permitiendo al mismo tiempo su ejecución e integración transparentes en la capa de orquestación declarativa de un flujo desencadenado por registro. Una vez definida la clase de `ServiceLevelAgreementCalculator` Apex, está disponible para su uso en un flujo desencadenado por registro: Este patrón demuestra una estricta separación de preocupaciones. La capa declarativa se utiliza para gestionar el ciclo de vida y la orquestación de transacciones mientras que el código se utiliza para la ejecución de alta complejidad. Al tratar el código como una utilidad funcional en vez de la base, equilibramos el desempeño y la capacidad de mantenimiento. #### Ganancias clave con el patrón híbrido **Modularidad**: La decisión se aleja de la singularidad de utilizar Apex o Flow para todo el proceso. En su lugar, la arquitectura encapsula lógica compleja en unidades discretas, seguras de forma masiva y comprobables de forma independiente. Estas unidades funcionan como componentes reutilizables consumidos por la capa declarativa, garantizando las escalas de automatización sin complicar el diseño arquitectónico. **Reutilización**: La lógica está desvinculada del evento desencadenador. Una unidad de código bien diseñada (como un `InvocableMethod`) se escribe una vez pero se aprovecha en múltiples puntos de entrada: Flujos desencadenados por registro, flujos de pantalla o integraciones externas. Esta reutilización de código elimina el desarrollo redundante. **Mantenibilidad**: La lógica de flujo de proceso permanece visible y gestionable en el Flujo declarativo. Esta centralización reduce drásticamente los gastos generales de depuración y garantiza que el orden de ejecución del sistema sea determinista y transparente. #### Limitaciones y ventajas del patrón híbrido Aunque el modelo híbrido de utilizar Apex invocable desde Flow es potente, no es un enfoque de talla única. Los arquitectos deben ser conscientes de las limitaciones y las ventajas específicas antes de comprometerse con una solución híbrida. - **Sin asistencia antes de guardar**: Esta es la limitación más crítica. Las acciones invocables solo están disponibles en el contexto después del guardado (flujos para acciones y registros relacionados). No se pueden utilizar en el contexto de alto desempeño antes del guardado (flujos para actualizaciones de campo rápidas). Por lo tanto, este patrón no se puede utilizar para delegar actualizaciones de campos del mismo registro. Realice ese trabajo de alto desempeño utilizando elementos Flujo nativos en un flujo antes de guardar o dentro de un desencadenador Apex antes de contexto. - **Sin compatibilidad después de la eliminación:** Flujo desencadenado por registro actualmente no admite el contexto posterior a la eliminación. Si un objeto de Salesforce tiene un requisito de negocio para ejecutar la automatización cuando se restaura un registro desde la papelera, un desencadenador Apex es la única solución. - **Carga de desempeño en escenarios de gran volumen:** La transición del tiempo de ejecución de Flujo al tiempo de ejecución de Apex no es una operación de costo cero. Aunque generalmente es rápido, el acto de soltar en una acción invocable desde el tiempo de ejecución de Flow no es tan rápido como la ejecución nativa que permanece completamente dentro de un desencadenador Apex. Para la mayoría de las automatizaciones de densidad media, esta microcarga es una ventaja insignificante y valiosa para la accesibilidad aumentada. Sin embargo, para escenarios de alto desempeño y gran volumen extremos, un marco de trabajo solo de Apex puro tendrá una ventaja de velocidad de cálculo sin procesar. ### Estrategias para la automatización heredada Aunque la heurística de densidad de automatización proporciona directrices definitivas para una arquitectura de campo nuevo más reciente, la realidad de los entornos de Salesforce de negocio suele ser más matizada. En organizaciones maduras, es común encontrar flujos desencadenados por registros y desencadenadores Apex operando en el mismo objeto de Salesforce. Este escenario es distinto del patrón híbrido explicado anteriormente: aquí, los flujos y desencadenadores Apex no están acoplados ni diseñados para funcionar juntos. Esta coexistencia es a menudo el resultado de la evolución de las funciones de la plataforma o de deudas técnicas heredadas. Aunque este es un estado operativo tolerado, los arquitectos deben tratarlo como una compensación calculada en vez de un estado final. La orquestación fragmentada causa una carga de trabajo de mantenimiento y regulación significativa, haciendo que las actividades de desarrollo, pruebas y gestión de incidentes sean inconexas y engorrosas. Esto lleva a un aumento del Tiempo de resolución (TTR) y la complejidad operativa. - Para nuevos objetos de Salesforce, respete el principio de densidad de automatización como la guía principal. - Para Objetos de Salesforce existentes con una huella híbrida y un desencadenador Apex dual y puntos de entrada de flujo desencadenados por registro, evalúe la densidad y luego cree arquitectos para refactorizar a un estado híbrido mantenible. - Para baja densidad, vuelva a factorizar desencadenadores Apex en flujos desencadenados por registros y especifique el orden de ejecución, llevándolos a un único punto de entrada de automatización. - Para densidad media, vuelva a factorizar megaflujos complejos en un subconjunto de flujos, con el orden de ejecución correcto. Introduzca desencadenadores Apex solo cuando sea absolutamente necesario, por ejemplo para dar cobertura después de cancelar la eliminación de contexto. - Para alta densidad, favor de implementar desencadenadores Apex. ### Uso de un marco de trabajo de metadatos para desencadenadores Apex A medida que maduran los procesos de negocio de una organización en Salesforce Platform, el volumen y la complejidad de la automatización desencadenada por registros aumentan inevitablemente. Una mejor práctica fundamental es mantener _un desencadenador Apex por objeto de Salesforce_. Esta regla es crítica porque la plataforma no garantiza el orden de ejecución de múltiples desencadenadores en el mismo objeto para el mismo evento. Esta limitación puede llevar a comportamientos no deterministas, condiciones de raza y problemas difíciles de depurar. Sin embargo, la adhesión al principio _de desencadenador único_ presenta un desafío arquitectónico: cómo gestionar y orquestar toda la lógica de negocio invocada desde ese único punto de entrada de una forma ampliable y mantenible. #### Las limitaciones de los controladores de desencadenadores Classic La primera evolución de esta arquitectura fue el patrón Classic Trigger Handler. En este enfoque, el desencadenador Apex único delega toda su lógica a una clase de controlador correspondiente (por ejemplo, `OpportunityTriggerHandler`). Este método separa la lógica del archivo desencadenador y proporciona a los desarrolladores un control determinista sobre el orden de ejecución dentro de los métodos de la clase de controlador (por ejemplo, `afterInsert()`). Aunque es una mejora, este patrón a menudo lleva a clases de controlador monolítico. Con el tiempo, a medida que se agregan más requisitos de negocio, la clase se vuelve grande, difícil de gestionar y difícil de probar de forma aislada. El orden de ejecución de todos los procesos individuales está codificado en un único método, lo que hace que la clase sea propensa a combinar conflictos, lo que aumenta drásticamente la regulación y los gastos generales de mantenimiento en un entorno de grandes compañías. #### La solución: Un marco de trabajo de desencadenador dirigido por metadatos Para resolver los problemas principales de modularidad y orquestación, los arquitectos cambian a un **Marco de trabajo** de desencadenador dirigido por metadatos. Este es un salto arquitectónico significativo que desvincula la lógica de automatización en sí de la configuración de _cómo_ y _cuándo_ se ejecuta. Este marco se basa en tres ventajas clave: - **Partición:** En vez de una única clase de gestor, la lógica de negocio principal se divide en clases de Apex atómicas pequeñas (por ejemplo, una clase de `RecalculateAccountValues` o una clase de `NotifySalesLeads`), respetando cada clase el _principio de responsabilidad_ única. Esta modularidad facilita la tarea de probar, depurar y comprender la lógica de forma aislada. - **Orden y coreografía:** La orden de ejecución ya no está codificada en Apex. En su lugar, se define declarativamente por registros de configuración, normalmente almacenados en un tipo de metadatos personalizados (por ejemplo, `TriggerAction__mdt`). Esto permite a los administradores reordenar, agregar o eliminar acciones de automatización simplemente modificando un registro de metadatos, que no requiere una implementación o cambio de código. - **Omitir funciones:** El marco de trabajo proporciona funciones de omisión granulares estandarizadas. Cada acción de automatización puede configurarse a través de su registro de metadatos para desactivarse de forma global o omitirse para usuarios administrativos específicos haciendo referencia a un permiso personalizado. El desencadenador de Apex único para el objeto sirve solo como un despachador dinámico. No contiene lógica de negocio, pero en su lugar crea una instancia de una clase de `MetadataTriggerHandler` central. Este controlador consulta los registros de metadatos personalizados para determinar dinámicamente la secuencia de ejecución e invocar las clases Apex atómicas correctas en el orden prescrito. La automatización está unificada bajo una capa única, transparente y gobernable. ### Desduplicación de operaciones costosas en la transacción Un beneficio importante de utilizar Apex en un marco de trabajo sólido es la capacidad de gestionar el estado de las transacciones y optimizar el desempeño eliminando el trabajo redundante. A medida que se acumula la lógica, es común que diferentes automatizaciones en la orden de guardado ejecuten de forma independiente las mismas operaciones costosas, consumiendo límites reguladores valiosos y aumentando el tiempo de operación DML. El marco está diseñado para abordar esto con dos estrategias principales: - **Gestión de estado compartido:** Dentro del ámbito de una única transacción Apex, las propiedades estáticas y las variables se aprovechan para almacenar en caché datos. Esto garantiza que una operación costosa, como una consulta de `SOQL` para un parámetro de configuración, solo se ejecute una vez, incluso si la lógica de automatización se invoca varias veces entre diferentes registros o fases del desencadenador. El consumo de límites de transacciones se reduce significativamente. - **Utilización de caché de plataforma:** Para ir más allá del simple almacenamiento en caché intratransacción, utilice la caché de plataforma para evitar consultar la base de datos completa para ciertos datos. Esta caché en memoria gestionada es ideal para recuperar datos que no son primitivos, leídos frecuentemente en la base de códigos e inmutables en el transcurso de una transacción (por ejemplo, perfiles, funciones, horarios laborales). Utilizando la interfaz de `Cache.CacheBuilder`, el sistema comprueba la caché primero y solo realiza la consulta de la base de datos si los datos no están presentes, maximizando el desempeño y la capacidad de ampliación. ### Utilizar antes del guardado para actualizaciones del mismo registro Utilice siempre una actualización antes del guardado cuando su automatización solo necesite cambiar valores de campo en el registro que inicia la transacción. Esto se aplica a actualizaciones de campo rápido en Flujo (que se ejecutan antes de guardar) y lógica antes de contexto en Desencadenadores Apex (antes de insertar, antes de actualizar). Este patrón es de desempeño, independientemente de la herramienta que se utilice, porque evita una segunda operación DML y un ciclo de guardado recursivo. Los cambios se realizan en el registro en memoria _antes_ de que se confirme en la base de datos y se guardan como parte de la transacción original. Se elimina la sobrecarga de un segundo guardado, que de lo contrario volvería a ejecutar la orden de guardado completa e iniciaría toda la automatización de nuevo. ### Evitar la repetición no controlada La recursión no controlada es un problema común en desencadenadores posteriores a la actualización, donde la lógica de un desencadenador realiza una actualización DML que a su vez provoca que el mismo desencadenador se active de nuevo. Esto crea un bucle infinito que termina finalmente con una excepción de límite regulador. Aunque históricamente se han utilizado indicadores booleanos estáticos o recopilaciones de Id. de registros procesados para evitar dicha repetición, un patrón más preciso y sólido es portar la lógica comparando valores de campo entre las versiones nueva y antigua del registro en sí. Ejecute la lógica solo si un campo de interés específico cambió realmente. Esto evita que el desencadenador ejecute su lógica en operaciones DML posteriores en la misma transacción donde los datos críticos permanecen sin cambios. #### Control de la recurrencia en flujos desencadenados por registros En un flujo desencadenado por registro, evite la repetición no controlada estableciendo el flujo para ejecutarse solo cuando se actualiza el registro para cumplir los requisitos de condición: Control de la recursión en flujo desencadenado por registro Si elige utilizar una fórmula de criterios de entrada en su flujo, puede evitar la repetición desbocada comparando la variable global de `$Record` (representando los nuevos valores) con la variable global de `$RecordPrior` (representando los valores originales antes del guardado). Por ejemplo, para asegurarse de que un flujo solo se ejecuta si el campo Importe en una oportunidad cambió, utilice esto en los criterios de entrada: ``` $Record.Amount != $Record__Prior.Amount ``` #### Control de la recurrencia en Apex Compare valores de campo de la nueva versión del registro, `Trigger.new`, con los valores de campo de la versión antigua del registro, `Trigger.oldMap`, para ver si se produjo el cambio específico que está buscando. Este enfoque garantiza que la automatización sea idempotente y solo se ejecute cuando sea necesario, haciendo que el sistema sea más eficiente y evitando bucles recursivos catastróficos. ### Omitir la automatización Una organización de Salesforce bien diseñada requiere un mecanismo coherente y fiable para omitir la automatización. Esta no es una función opcional, sino un requisito operativo principal para mantener la integridad de los datos y activar tareas administrativas. Un marco de trabajo de omisión es esencial para algunos escenarios: - Cuando se cargan grandes volúmenes de datos, la activación de desencadenadores para cada registro puede ralentizar drásticamente el proceso, provocar excepciones de límite y crear notificaciones y registros relacionados erróneos. Una omisión permite insertar los datos de forma limpia y eficiente. - Un usuario de integración puede necesitar sincronizar datos desde un sistema de registro externo. La automatización que normalmente se desencadena para un cambio iniciado por el usuario (por ejemplo, el envío de un email, la creación de una tarea) puede ser indeseable o redundante cuando el cambio se origina desde otro sistema. - Es posible que los administradores o el personal de asistencia necesiten realizar actualizaciones correctivas en registros. Un mecanismo de omisión les permite realizar estos cambios sin desencadenar la automatización de negocio estándar, lo que podría tener consecuencias no deseadas. **Permisos personalizados**: El estándar moderno y ampliable para la implementación de la lógica de omisión son los permisos personalizados. Estos métodos son superiores a los antiguos por varias razones: - **Flexibilidad:** Los permisos personalizados se pueden asignar a usuarios a través de conjuntos de permisos. Esta práctica se alinea con el modelo moderno de acceso y seguridad de Salesforce, permitiendo una asignación granular y flexible. Se puede otorgar una omisión a un usuario específico, o incluso temporalmente con una fecha/hora de caducidad específica. - **Mantenibilidad:** El uso de permisos personalizados evita codificar perfiles o usuarios en lógica de automatización. Si la función de un usuario cambia o un nuevo perfil necesita omitir el acceso, el cambio es una asignación de Conjunto de permisos sencilla, no una modificación de flujo o código que requiere una implementación. - **Escalabilidad:** Los permisos personalizados proporcionan un marco de trabajo ampliable para gestionar excepciones en una base de usuarios compleja. Se pueden asignar a usuarios a través de conjuntos de permisos, grupos de conjuntos de permisos o perfiles. Su asociación a un conjunto de permisos o perfil también es representable en metadatos de origen. **Patrones de implementación**: Aplique un patrón de omisión coherente a todas las automatizaciones desencadenadas por registros en la organización. **Omitir un flujo desencadenado por registro**: La forma más eficiente de omitir un flujo es evitar que se ejecute. Esto se logra agregando una condición a los criterios de entrada del flujo. - En el elemento Inicio del flujo desencadenado por registro, establezca los Requisitos de condición en La fórmula se evalúa como Verdadero. - En el generador de fórmulas, incorpore una comprobación para el permiso personalizado utilizando la variable global `$Permission`. Combine la comprobación con sus criterios de entrada existentes. - Patrón de fórmula: ``` ( ) && NOT($Permission.Bypass_This_Flow) ``` - Este patrón garantiza que el flujo solo se ejecute si el usuario _no_ tiene el permiso personalizado especificado asignado. Esta comprobación se realiza incluso antes de que se cree la entrevista de flujo, lo que la convierte en el enfoque con mayor desempeño. **Omitir un marco de trabajo desencadenador Apex**: En Apex, integre la lógica de omisión directamente en el marco de desencadenador dirigido por metadatos, permitiendo un control granular. - El tipo de metadatos personalizados de `TriggerAction__mdt` debe incluir un campo de texto, por ejemplo, `BypassPermission__c`. - En la clase `MetadataTriggerHandler`, antes de ejecutar una acción de forma dinámica, el código debe leer el valor de este campo. - Si el campo se rellena, el controlador utiliza el método `FeatureManagement.checkPermission()` para determinar si el usuario que ejecuta actualmente tiene el permiso personalizado especificado. - Si `checkPermission()` devuelve true, el controlador omite esa acción específica y continúa con la siguiente en la secuencia. - Este patrón es potente porque permite una omisión global (si todos los registros de `TriggerAction__mdt` hacen referencia al mismo permiso) y una omisión granular por acción (si diferentes registros hacen referencia a diferentes permisos, o algunos no tienen ningún permiso de omisión). ### Megaflujos frente a múltiples flujos Es un antipatrón para consolidar toda la automatización de un objeto en un único flujo masivo. La consolidación en un flujo frente a la división de la lógica en múltiples flujos bien acondicionados no tiene un impacto importante en el desempeño. Las ganancias de desempeño más significativas provienen de: - Uso de flujos antes de guardar para actualizaciones de campos del mismo registro. - Redactar condiciones de entrada precisas para garantizar que los flujos no se ejecutan en cambios que no afectan a su caso de uso específico. [Flow Trigger Explorer](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) le permite asignar un valor de pedido a cada flujo en un objeto, garantizando un orden de ejecución secuencial. Explorador de desencadenadores de flujos ## Recursos
Apex Flujo Operaciones
# Determinación de la automatización de flujos de trabajo agentes y tradicionales Con Agentforce, las compañías ahora pueden desbloquear nuevos paradigmas para el trabajo automatizado que no se pueden reducir fácilmente a reglas. Estas nuevas funciones incluyen la resolución de intenciones de clientes desde pláticas no estructuradas, la coordinación de procesos de múltiples partes entre sistemas y la respuesta a condiciones operativas en tiempo real. Los flujos de trabajo de agentes utilizan automatización diseñada para razonar hacia resultados en vez de ejecutar pasos predefinidos. Cumplir esta demanda requiere una plataforma que opere en todo el espectro de complejidad de automatización y un marco de trabajo que muestre dónde se ajusta cada función. Agentforce combina Einstein Trust Layer, Reasoning Engine, Agent Script, Flow, Apex y Data 360 en una única plataforma unificada. Esta combinación gestiona todo, desde una sencilla automatización de desencadenadores de registros a una compleja orquestación de múltiples agentes entre voz, visión, documentos y telemetría en tiempo real. MuleSoft amplía esta plataforma con la estructura, la gobernanza y la orquestación entre sistemas de MuleSoft necesarias para conectar flujos de trabajo de agentes en una compañía. Agentforce Operations (anteriormente Agentforce Supply Chain) aplica estas funciones a las demandas específicas de procesos operativos y de fabricación. ## Descripción general de guía Esta guía presenta el marco de trabajo Densidad de orquestación y directrices para tomar decisiones fundamentadas en este panorama de productos. El marco de trabajo proporciona a los arquitectos un enfoque repetible para seleccionar las herramientas y los patrones correctos utilizando niveles de densidad para casos de uso de automatización inteligente en Salesforce Platform. ## Productos en ámbito | Producto | Descripción | | :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agentforce | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) es la plataforma de Salesforce para construir y desplegar agentes de IA. Utiliza el motor Atlas para desencadenar acciones en tiempo real fundamentadas dinámicamente a través de Apex y Data 360. | | Script de agente | [Script de agente](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) es un lenguaje declarativo específico de dominio (DSL) utilizado en Agentforce Builder para definir flujos de trabajo, reglas de negocio y lógica conversacional para agentes | | Agentforce Grid | [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) es una interfaz parecida a una hoja de cálculo nativa de IA sin código para diseñar y poner en marcha rápidamente flujos de trabajo de IA a escala. | | Operaciones Agentforce | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (anteriormente Agentforce Supply Chain) es una plataforma de orquestación de gestión de flujos de trabajo colaborativos con tecnología de IA diseñada para simplificar y automatizar los procesos institucionales internos. | | MuleSoft | [MuleSoft](/docs/architect/es-mx/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) es una plataforma integral, unificada y abierta para la integración de la compañía y la gobernanza de agentes. A través de la conectividad dirigida por API y MuleSoft Agent Fabric y Agent Broker, sirve como el tejido de integración, la capa de gobernanza y la base de orquestación entre sistemas para conectar flujos de trabajo de agentes en toda la compañía | | Flujos y Apex | [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) es una potente herramienta de automatización de apuntar y hacer clic para crear procesos de negocio complejos visualmente sin código. [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) es un lenguaje de programación patentado y orientado a objetos para la plataforma Salesforce, similar a Java. Se utiliza para crear lógica de negocio personalizada, automatizar procesos y ampliar funciones de CRM principales más allá de herramientas declarativas. | ## Comida para llevar Agentforce representa un cambio fundamental en el modo en que se realiza el trabajo en Salesforce Platform, desde la automatización basada en reglas a flujos de trabajo basados en razonamiento. Para liberar su potencial, los arquitectos deben tomar decisiones fundamentadas y deliberadas sobre dónde se ajustan los agentes, cómo se componen y qué orquestan. Los siguientes principios proporcionan una directriz repetible para decisiones de agentes. - **Utilice la herramienta correcta para la tarea correcta.** Utilice la densidad de orquestación en base a la ruta de ejecución, la combinación de modalidades y la complejidad de objetivos para determinar la mejor solución de ajuste. - Utilice la **automatización tradicional** con flujos y Apex para el trabajo determinista basado en reglas, donde el resultado puede tener un ámbito completo y definirse por un conjunto de reglas. La automatización tradicional da como resultado una ruta de ejecución estática, que garantiza resultados predecibles y repetibles y es crucial para la capacidad de auditoría. Seleccione la automatización tradicional para tareas que exigen cumplimiento estricto y adhesión legal. - Utilice **Agentforce Grid** para casos de uso de inferencia masiva con complejidad de orquestación baja a media. Este patrón utiliza el razonamiento generativo de un solo turno para clasificar, puntuar o resumir datos en un alto volumen de registros de CRM, garantizando una ejecución de alto rendimiento con capacidad de auditoría inmediata. - Utilice **Agentforce con Agent Script** para tareas que tienen objetivos abiertos donde se conoce el resultado deseado, pero no se puede especificar la ruta de ejecución exacta en el momento del diseño. Aplique este patrón a requisitos que requieren razonamiento a través del determinismo guiado, para garantizar resultados predecibles y trazables. - Utilice **Agentforce Operations** para simplificar y automatizar procesos de negocio de colaboración con gestión activada por IA para flujos de trabajo de cadena de suministro. - **Evite aplicar flujos de trabajo de agentes a casos de uso de baja densidad de orquestación**. Evalúe las compensaciones entre la automatización tradicional y la de agentes para requisitos funcionales y no funcionales. La automatización tradicional puede ofrecer la escala, la fiabilidad y el desempeño requeridos para su caso de uso. - **Adopte un enfoque híbrido** de automatización de agentes, que combina Agentforce y la automatización tradicional con Flujos y Apex, cuando esta sinergia ofrece mayor valor que el uso de la automatización tradicional o agente de forma aislada. ## Puntos de decisión El sObject de Salesforce es tradicionalmente el punto de entrada principal para la automatización de registros. El sistema ejecuta lógica basada en reglas, comenzando inmediatamente después de un evento de Lenguaje de manipulación de datos (DML) como insertar, actualizar o eliminar. Para decidir entre herramientas para una [automatización desencadenada por registros](/docs/architect/es-mx/decision-guides/guide/record-triggered.html) eficiente, presentamos [Automation Density](/docs/architect/es-mx/decision-guides/guide/record-triggered#automation-density.html) como un medio para medir la complejidad del sistema, considerando la cantidad de automatización, el volumen de registros y la expansión de dependencias. La automatización tradicional está limitada por el amplio trabajo previo requerido para aportar datos en una construcción estructurada, que cumpla esquemas y basada en reglas. La automatización agente actualiza la automatización tradicional utilizando la intención del usuario o datos no estructurados como la entrada donde se puede aplicar el razonamiento para alcanzar el resultado deseado. Los arquitectos deben decidir cuándo aprovechar el razonamiento probabilista para datos no estructurados multimodales y cuándo aplicar flujos de trabajo guiados y deterministas para mitigar el riesgo de resultados impredecibles. Cuando el requisito cambia de la ejecución de pasos basados en reglas al razonamiento hacia resultados, los arquitectos necesitan un marco de trabajo estandarizado para evaluar la profundidad del razonamiento y la complejidad de los objetivos de la solución propuesta. ### Densidad de orquestación La densidad de orquestación es la medición de la complejidad en un flujo de trabajo de agente. Tres factores determinan la densidad de orquestaciones: ruta de ejecución, complejidad de objetivos y combinación de modalidades. Aunque la densidad de automatización mide la complejidad física de las reglas y el volumen del sistema, la densidad de orquestación mide la complejidad de razonamiento de la ruta del agente hacia un objetivo. Utilice la densidad de orquestación compuesta para evaluar sus requisitos de diseño y asignar al estándar arquitectónico. - **Ruta de ejecución**: Grado en que el flujo de trabajo puede tener un ámbito completo y especificarse en tiempo de diseño. Un flujo de trabajo completamente especificado significa que el flujo de trabajo define cada bifurcación y resultado dando como resultado una ruta de ejecución predeterminada. Un flujo de trabajo no especificable tiene una ruta que puede emerger durante el tiempo de ejecución a través del razonamiento frente a instrucciones y datos contextuales. - **Complejidad de objetivos**: El número de resultados, puntos de decisión y variaciones de ruta distintos que el flujo de trabajo debe resolver en tiempo de ejecución. Un flujo de trabajo de baja complejidad gestiona una única tarea contenida con un resultado predeterminado, mientras que un objetivo de alta complejidad abarca múltiples etapas con objetivos competidores o en conflicto con casos extremos que no se pueden anticipar en el momento del diseño. - **Mezcla de modalidades**: La gama de tipos de entrada que debe procesar un flujo de trabajo y los formularios de salida que debe producir. Una mezcla de modalidad baja lee campos estándar de CRM y produce actualizaciones de registro. Una modalidad media consume una mezcla de campos de CRM estructurados y datos estáticos no estructurados, como cuerpos de email o transcripciones de casos, para producir actualizaciones de registros. Una mezcla de alta modalidad consume transmisiones dinámicas en tiempo real, como audio en vivo o telemetría, y produce resultados multimodales entre múltiples sistemas externos. ![Diagrama de marco de trabajo Densidad de orquestación mostrando ejes de ruta de ejecución, complejidad de objetivos y combinación de modalidades](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png) ### Secuenciación de factores La determinación del nivel de densidad de orquestación apropiado requiere evaluar secuencialmente la ruta de ejecución, la complejidad de objetivos y la combinación de modalidades. Inspeccione la ruta de ejecución primero. Si una ruta es completamente especificable, comience con la automatización tradicional. El uso de una solución Agentic solo para orquestar y ejecutar una ruta determinista sin ningún requisito de razonamiento es un antipatrón. Esto lleva a la dispersión de agentes (proliferación excesiva y no gestionada de agentes de IA) y a la desorganización de agentes (salida innecesaria y de baja calidad generada por IA), lo que da como resultado devoluciones de valor deficientes. Para rutas parciales o no especificables, siga evaluando la complejidad de los objetivos. Si la complejidad del objetivo está bien definida pero ciertos nodos a lo largo de la ruta necesitan evaluaciones probabilistas, considere llamar a agentes desde Flow o Apex para satisfacer la necesidad localizada específica. En su lugar, si los pasos en la ruta de ejecución necesitan uno o más requisitos dirigidos por IA en un gran conjunto de registros, considere Agentforce Grid. Cuadrícula admite flujos de trabajo basados en hojas de múltiples pasos a través de múltiples columnas de IA o agente. Es el más adecuado para la ejecución masiva orientada a filas. Este enfoque garantiza que el flujo de trabajo siga teniendo un alto desempeño y capacidad de auditoría, invocando el razonamiento probabilista solo donde no se puede predefinir la ruta. A medida que aumenta la complejidad de los objetivos con dimensiones competidoras (por ejemplo, determinando un pago de reclamación de seguro junto con la detección de fraude, el cumplimiento de pólizas y la satisfacción del cliente) y rutas de ejecución no especificables, considere Agentforce con Script de agente para un determinismo guiado en su automatización. Para casos de uso entre compañías que implican Salesforce y sistemas externos, utilice MuleSoft Fabric y Agent Broker. Finalmente, evalúe la combinación de modalidades para identificar las funciones técnicas necesarias, como la conexión multimodal o la integración especializada. La mezcla de modalidades funciona como un selector de capacidad, no como una calculadora de densidad. Ayuda a determinar la infraestructura requerida para gestionar la forma de entrada y salida de la solución, sin alterar su lógica de orquestación fundamental. ### Matriz de selección de densidad Utilice esta matriz para determinar el estándar arquitectónico para su automatización de agentes. Equilibre la automatización tradicional y la automatización de agentes seleccionando el enfoque que resuelve su problema de automatización. - **Automatización tradicional (baja densidad de orquestación):** Utilice la automatización tradicional cuando el proceso se desencadena por un cambio de registro, los datos están estructurados, la lógica está basada en reglas y predeterminada y el resultado debe ser predecible (por ejemplo, cálculos de precios estándar o creación de tareas automáticas). - **Agentforce Grid (densidad de orquestación baja a media):** Utilice Agentforce Grid cuando se deben procesar tareas de IA masivas entre registros existentes (por ejemplo, resuma los últimos 50 casos para cada Cuenta en esta lista, calcule el puntuaje de opiniones y mantenga el puntuaje en el campo de caso). - **Orquestación híbrida (Automatización aumentada de orden superior):** Utilice la orquestación híbrida al automatizar un proceso de negocio complejo de extremo a extremo (por ejemplo, procesamiento de reclamaciones o incorporación) que requiere las funciones de planificación de la IA pero la integridad de las transacciones de Flow y Apex. - **Script de agente Agentforce (Complejidad de alta intención):** Utilice Script de agente cuando el punto de entrada no esté estructurado (por ejemplo, chat, email y voz) y la resolución requiera una plática o la capacidad de gestionar solicitudes de usuario ambiguas. | Nivel de densidad | Ruta de ejecución | Complejidad de objetivos | Mezcla de modalidades | Estándar arquitectónico | | :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Bajo** | Completamente especificable | **Bajo:** Tarea incluida única con resultados predefinidos. | **Modalidad única:** Lee y redacta registros de objetos de Salesforce estructurados. | Automatización desencadenada por registro. Si el caso de uso tiene al menos una tarea de razonamiento, utilice Acciones de agente en el flujo de trabajo. | | **Bajo - Medio** | Total o parcialmente especificable | **Bajo:** Serie de pasos con resultados predefinidos. | **Modalidades mixtas:** La entrada o la salida pueden tener una mezcla de datos estructurados y no estructurados. | Utilice Inferencias por lotes de cuadrículas Agentforce para tareas masivas en registros existentes con acción de agente. | | **Medio** | Especificable total o parcialmente. La ruta de ejecución está predefinida, pero los pasos intermedios necesitan razonamiento. | **Medio:** Serie de pasos basados en Apex o Flow con resultados de variable. | **Modalidades mixtas:** La entrada o la salida pueden tener una mezcla de datos estructurados y no estructurados de bajo volumen. | Híbrido (Agentforce + Apex): Utilice Agentforce para razonamiento y planificación de alta densidad, Script de agente para determinismo guiado y Apex / Flujo para orquestación. | | **Alto** | Parcial o no especificable. El objetivo está predefinido, pero los pasos intermedios necesitan contexto de tiempo de ejecución e intención de usuario. | **Alto:** Múltiples objetivos competidores con necesidades de razonamiento pesadas requieren resultados deterministas. | **Modalidades mixtas:** La entrada o la salida pueden tener una mezcla de datos estructurados y no estructurados de gran volumen que llegan en tiempo real. | Utilice Script de agente para equilibrar el control determinista con el razonamiento. Utilice MuleSoft Agent Fabric para MCP externos o A2A para una colaboración compleja de múltiples agentes. | ## Comparación de productos | Capacidad | Automatización tradicional (Flujo / Apex) | Agentforce Grid | Agentforce | Agentforce con secuencia de comandos de agente | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Tipo de lógica y determinismo** | **Determinista:** Utiliza lógica fija if-then-else. La ruta de ejecución es 100% predecible basándose en el estado del registro. | **Mixto:** Determinista a través de pasos estructurados mientras que los pasos de IA individuales pueden ser probabilistas. | **Probabilista:** Utiliza el razonamiento de múltiples turnos para determinar la mejor ruta hacia un objetivo. | **Determinismo guiado:** Utiliza el razonamiento para planificar la ruta y permite la ejecución en rutas de nodos deterministas. | | **Velocidad de entrega** | **Recomendado (Flujo):** Las herramientas visuales permiten la creación rápida de lógica desencadenada por registro sin código. | **Recomendado para automatización de IA repetitiva:** La forma más rápida de aplicar lógica de IA entre conjuntos de registros existentes sin crear nuevos flujos. | **Recomendado:** Para la configuración de Subagentes (anteriormente Temas), Instrucciones y Asignación de habilidades para un dominio o problema específico. | **Recomendado:** Para la asignación avanzada de gráficos basados en estado y lógica de borde. | | **Modalidad de entrada** | **Recomendado solo para estructurado:** Limitado a campos de CRM y recopilaciones de registros relacionados. | **Recomendado para semiestructurado:** Procesa texto masivo (descripciones, transcripciones) desde campos de registro. | **Recomendado para Multimodal:** Procesa lenguaje natural, voz y visión (datos no estructurados). | **Recomendado para alta densidad:** Sintetiza entradas multimodales con datos de estado del sistema en tiempo real. | | **Profundidad de razonamiento (Planificación)** | **No disponible:** La lógica es imperativa; no puede "pensar" ni planificar pasos de forma dinámica. Sin embargo, los datos se pueden enviar a agentes. | **Bajo:** Inferencia de un solo paso aplicada en un conjunto de registros (IA por lotes). | **Medio/Alto:** Utiliza bucles de razonamiento (Motivo-Acto-Observación) para resolver intenciones complejas. | **Gobernado:** El razonamiento está restringido a la navegación por un gráfico predefinido de estados de negocio. | | **Modularidad y reutilización** | **Recomendado:** Modular de forma predeterminada a través de subflujos y clases Apex. | **Limitado:** La lógica suele estar vinculada a la fila de cuadrícula específica. Las configuraciones de columnas y los flujos de trabajo con plantilla se pueden reutilizar en todo el conjunto de filas. | **Disponible:** Las habilidades (Flujos / Apex) se reutilizan entre diferentes subagentes (anteriormente Temas) y agentes conectados. | **Recomendado:** Los nodos en el Gráfico de agente son unidades funcionales reutilizables discretas. | | **Control de transacciones y DML** | **Recomendado (Apex):** Control completo sobre Savepoints, reversiones y masificación. | **Disponible:** Cada fila se procesa de forma independiente, de modo que el ámbito de ejecución es por registro. | **Limitado:** Las acciones se ejecutan como pasos individuales desvinculados en una sesión. | **Recomendado:** Utiliza nodos Flujo / Apex para servir como delimitadores deterministas para todos los DML. La compatibilidad de control de transacciones distribuidas entre agentes es limitada. | | **Gestión de ambigüedades** | **No disponible:** Requiere rutas predefinidas. La entrada inesperada lleva a errores estáticos o fallos. | **Limitado:** La calidad de salida depende de la fundamentación de solicitudes. El flujo de trabajo no puede solicitar aclaraciones de forma interactiva. | **Recomendado:** Gestiona estados "desconocidos" formulando preguntas o seleccionando habilidades alternativas. | **Disponible:** Utiliza "Nodos de reserva" para gestionar fallos de razonamiento o tiempos de espera de procesos. | | **Visibilidad y gobernanza** | **Recomendado:** El Explorador de desencadenadores de flujos proporciona un mapa visual de toda la lógica desencadenada por registros. | **Disponible:** La interfaz de usuario basada en cuadrículas proporciona una visibilidad clara de los resultados a nivel de filas y admite la capacidad de auditoría de resultados. | **Disponible:** Los registros de monitoreo proporcionan transparencia sobre cómo tomó decisiones el agente. | **Requiere experiencia:** Requiere monitorear los registros de trayectoria de gráfico y de inferencia LLM. | | **Desempeño y escala** | **Recomendado** Optimizado para procesamiento de registros síncronos de gran volumen. | **Recomendado** Procesa eficientemente tareas de IA masivas entre grandes volúmenes de datos. | **Latencia** Dependiendo del tiempo de inferencia; inadecuado para actualizaciones masivas de alta densidad. | **Moderado** Adecuado para tareas complejas de largo horizonte, pero tiene una carga superior. | ## Casos de uso Esta tabla proporciona recomendaciones generales para varios casos de uso. | Caso de uso | Descripción | Mejor ajuste | Justificación | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Procesamiento de registros** | Automatización desencadenada por un evento DML en un objeto estructurado de Salesforce donde cada sucursal y resultado se pueden definir completamente en tiempo de diseño. | Utilice el flujo desencadenado por registro. Esta es una automatización tradicional de baja densidad. | Baja densidad de orquestación. Modalidad única (campos de CRM estructurados) y un objetivo contenido único con una ruta de ejecución predecible y auditable. | | **Control de transacciones con lógica compleja** | Automatización que requiere puntos de guardado, reversiones, confirmaciones parciales o manipulación de datos segura de forma masiva entre grandes volúmenes de registro. | Utilice Apex para la automatización determinista tradicional de baja densidad. | Baja densidad de orquestación. Apex proporciona un control completo sobre la integridad de las transacciones, la deduplicación de cálculos costosos y el almacenamiento en caché a nivel de plataforma: funciones no disponibles en Flow. | | **Lógica moderadamente compleja en un proceso estructurado** | Automatización donde el proceso general está basado en reglas pero los pasos individuales requieren computación o manipulación de datos más allá de la capacidad declarativa. | Utilice Flujo con Apex invocable para lógica determinista de baja densidad. | Baja densidad de orquestación. Flujo actúa como la capa de orquestación; Apex invocable encapsula operaciones de alta complejidad como componentes reutilizables y seguros de forma masiva. | | **Procesamiento programado y temporal** | Automatización que debe ejecutarse en una fecha futura calculada dinámicamente en relación con un evento de registro. | Utilice la automatización tradicional (flujos desencadenados por registros) para un procesamiento determinista de baja densidad. | Baja densidad de orquestación. Las [rutas programadas de](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5) flujos proporcionan programación, cancelación y reprogramación automáticas si cambian los datos del registro, que no están disponibles de forma nativa en desencadenadores Apex. | | **Inferencia de registro masivo** | Aplicación de un único paso de razonamiento de IA de forma uniforme entre un gran conjunto de registros existentes para generar una clasificación, resumen o puntuaje. | Utilice Agentforce Grid para la inferencia por lotes y para utilizar funciones de agente repetitivas a escala. | Densidad de orquestación media. Inferencia por lotes con modalidad única a escala: el agente lee campos de registro estructurados y escribe una salida uniforme de vuelta en cada registro. Complejidad de objetivos baja con un patrón de inferencia repetitivo. | | **Resolución de entrada no estructurada** | Automatización donde el punto de entrada es una solicitud de lenguaje natural, email o plática que debe interpretarse, clasificarse y resolverse a través del razonamiento. | Utilice Agentforce para una resolución de entrada no estructurada, dirigida por intención y de densidad media. | Densidad de orquestación media. Modalidad mixta: el agente consume entrada conversacional no estructurada, luego produce respuestas de texto o actualizaciones de registros estructurados. El objetivo requiere resolver la intención del usuario en un conjunto limitado de resultados. | | **Lógica moderadamente compleja en un proceso probabilista** | Automatización donde el proceso general está basado en reglas, pero los pasos individuales requieren funciones de IA como resumen o recuperación de RAG. | Utilice Flujo con Apex invocable y Plantillas de solicitud para procesos deterministas de baja densidad que requieren funciones de IA. | Densidad de orquestación media. Flujo actúa como la capa de orquestación mientras que [Plantillas de solicitudes](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api), [Agente de servicio](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) y Agentforce Employee están expuestos como acciones invocables. | | **Orquestación de procesos guiada** | Automatización que abarca flujos de trabajo de múltiples pasos donde la finalización de una acción desencadena acciones adicionales | Utilice [Script de agente](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining) para rutas de ejecución de alta densidad no especificadas que requieren orquestación de procesos guiada. | Alta densidad de orquestación: modalidad mixta entre entrada y salida. Resultados competidores y casos extremos que no se pueden anticipar completamente en el momento del diseño. Script de agente proporciona determinismo guiado. | | **Orquestación de procesos entre sistemas** | Automatización coordinando un proceso de negocio de múltiples pasos entre múltiples sistemas backend donde ningún sistema es propietario del flujo de extremo a extremo | Utilice la API de procesos de MuleSoft con Agent Broker para la orquestación de procesos entre sistemas de densidad media y alta. | Alta densidad de orquestación: las API de procesos encapsulan lógica de negocio de múltiples pasos compleja de modo que los agentes no necesitan comprender la orquestación detrás de operaciones como el procesamiento de pedidos o las comprobaciones de inventario. [El corredor de](https://www.mulesoft.com/ai/agent-broker) agentes secuencia e invoca dinámicamente agentes y herramientas requeridos desde un único objetivo de lenguaje natural. | | **Abstracción del sistema backend** | Orquestación donde los agentes deben interactuar con sistemas heredados, bases de datos o plataformas SaaS externas que carecen de conectividad Agentforce nativa. | Utilice MuleSoft con el conector MCP para ajustar sistemas heredados y proporcionar contexto de modelo. | Densidad de orquestación media. Las API del sistema ofrecen una interfaz segura y abstracta con sistemas de registro, garantizando que los flujos de trabajo de agentes se desvinculen de la complejidad del backend. El Conector MCP transforma aplicaciones MuleSoft en servidores compatibles con MCP para la capacidad de detección e invocación inmediatas. | | **Procesamiento de documentos de gran volumen y gestión de excepciones** | Automatización que lee, interpreta y reconcilia documentos estructurados y semiestructurados entrantes con registros existentes a escala: gestión de variaciones, coincidencias parciales y excepciones con la intervención manual apropiada. | Utilice Agentforce Operations para el procesamiento de documentos de gran volumen dirigido por intención y densidad media. | Densidad de orquestación media con modalidad de entrada semiestructurada. Complejidad de objetivos dirigida por reglas de coincidencia, rutas de excepción y umbrales de aprobación por documento. Requiere razonamiento por registro, no inferencia uniforme de un solo turno. | | **Orquestación de múltiples agentes entre proveedores** | La automatización requiere colaboración entre agentes especializados creados en diferentes plataformas o proveedores. | Utilice MuleSoft con Conector A2A y Tela de agente para la orquestación de múltiples agentes entre diferentes sistemas. | Densidad de orquestación media a alta. El Conector A2A permite flujos de trabajo de múltiples agentes de punto a punto con fiabilidad y gobernanza de nivel de compañía, independientemente de dónde esté construido o alojado cada agente. | | **Conversión de documento no estructurado a flujo de trabajo** | Automatización donde los procesos operativos definidos en orígenes no estructurados (SOP, documentos de reglas de proveedores o diagramas de procesos) deben convertirse en flujos de trabajo agentes ejecutables sin codificación manual. | Utilice Agentforce Operations para la conversión de documentos no estructurados emergentes de alta densidad a flujo de trabajo. | Alta densidad con una alta mezcla de modalidades en la entrada. Ingresa PDF, documentos de Word y diagramas basados en imágenes. Complejidad de objetivos determinada por el ámbito y la bifurcación del proceso ingresado. La ruta de ejecución no se puede especificar en el momento del diseño. | | **Orquestación multipartita** | Automatización que abarca la incorporación coordinada de partes externas: recopilación de datos requeridos, verificación del cumplimiento, gestión de aprobaciones y actualización de sistemas de registro entre muchos seguimientos de incorporación simultáneos. | Utilice Agentforce Operations para una orquestación de densidad media a alta, dirigida por la intención a múltiples partes emergentes. | Múltiples pasos de verificación y aprobación interdependientes deben resolverse secuencialmente antes de que se complete la incorporación. La combinación de modalidades incluye registros estructurados, documentos no estructurados y comunicaciones de partes externas. | | **Intervención de activos predictiva** | Automatización donde un motor predictivo ingresa telemetría en tiempo real para identificar condiciones de fallo inminentes y desencadena una respuesta de back-office de múltiples pasos coordinada. | Utilice Agentforce Operations y Agentforce for Manufacturing para la intervención de activos predictiva de alta densidad. | Data Cloud gestiona la telemetría de IoT de alta modalidad y la detección de anomalías. Agentforce Operations orquesta a continuación el flujo de trabajo de back-office de modalidad media (gestión de registros de servicio de campo, datos de inventario y comunicaciones de clientes) resolviendo el proceso de extremo a extremo. | | **Gestión de comunicación de proveedores a gran escala** | Automatización de la gestión de comunicaciones estructuradas y semiestructuradas en curso en una gran base de proveedores, incluyendo confirmaciones de pedidos, cambios de fecha de entrega y notificaciones de excepciones. | Utilice Agentforce Operations para Inferencias por lotes en una gestión de comunicación de proveedor de densidad media. | Donde las comunicaciones son uniformes entre proveedores, utilice Agentforce Grid para el procesamiento por lotes. Donde las respuestas requieren razonamiento contextual por relación de proveedor, distribuya a densidad media con Agentforce Operations. | | **Gestión de prospectos (Enrutamiento inteligente de alta velocidad)** | Automatización que ingresa respuestas de marketing en tiempo real, utiliza el puntuaje de IA y el enriquecimiento de Data Cloud para la cualificación, y utiliza flujos para la asignación inteligente de subminutos y el enrutamiento de prospectos de alta calidad al equipo de ventas apropiado. | Utilice Automatización tradicional (Flujo) + Data Cloud e IA para el enrutamiento de prospectos inteligente de alta velocidad de densidad media. | Requiere alta velocidad (Velocidad de prospecto < 1 min) y enrutamiento complejo dirigido por datos basándose en puntuaje de prospectos de IA, nivel de trabajo e historial de actividad. Utiliza flujos para una lógica de asignación rápida y determinista, aumentada por IA probabilista y Data Cloud para la cualificación y el enriquecimiento de prospectos. | | **Fomento de prospectos** | Fomenta prospectos de bajo puntuaje hasta que estén listos para una plática de ventas. | Utilice Agente de refuerzo de prospectos para dirigir y mejorar prospectos de baja calidad para la automatización de densidad media a alta. | Envía emails personalizados de múltiples contactos basados en datos de prospectos e historias de éxito de clientes. Gestiona respuestas de email y utiliza Flujo para la transferencia. | | **Calificación de prospectos entrantes** | Cualifica y fomenta prospectos entrantes de mayor puntuaje de forma autónoma. | Utilice Agente de apoyo de prospectos para cualificar e implicar prospectos. | Ejecuta email saliente de múltiples contactos, reserva de reuniones, preguntas y respuestas sobre productos y gestión de objeciones. Puede operar en modo "enviar como vendedor", enviando emails a través del propietario del prospecto asignado. | ## Asignación de casos de uso ![Diagrama de asignación de casos que muestra varios escenarios de automatización entre niveles de densidad de orquestación](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png) ## Consideraciones no funcionales **Latencia** Los flujos desencadenados por registro síncronos se ejecutan en la transacción de plataforma y se completan en milisegundos. El tiempo de inferencia Agentforce depende del Motor de razonamiento Atlas y se amplía con la profundidad de razonamiento y la complejidad de la modalidad. Agentforce no es adecuado para el procesamiento de registros síncronos de gran volumen donde la latencia es una restricción principal. **Costo** El costo de razonamiento de un flujo de trabajo de agente debe justificarse con el valor de negocio del resultado. Para tareas de alto volumen y baja densidad de orquestación donde existe una ruta determinista, la automatización tradicional o Agentforce Grid podría ser más económica que un flujo de trabajo agente de extremo a extremo. Asegúrese de que el diseño acomoda el patrón de reintento correcto con límites de reintento máximo explícitos y disyuntores. Esta barandilla limita el riesgo de sobrecoste de composición asociado con el procesamiento masivo. **Límites reguladores** Evalúe flujos de trabajo de agentes de gran volumen frente a límites de plataforma diarios para una ejecución asíncrona. Las operaciones por lotes de Agentforce Grid siguen los límites de transacciones de plataforma estándar. Para la automatización que implica Objetos de Salesforce, considere el número total diario de operaciones DML, ya que Salesforce aplica la gestión de recursos compartidos en un entorno de múltiples arrendatarios y [limita](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150) para evitar que las automatizaciones descontroladas monopolicen recursos compartidos. **Auditabilidad y cumplimiento** La automatización tradicional produce seguimientos de ejecución completamente auditables a través del Explorador de desencadenadores de flujos y registros Apex. Los patrones híbridos o de extremo a extremo basados en Agentforce producen registros de razonamiento que proporcionan transparencia en la toma de decisiones de agentes, pero requieren experiencia para interpretar. El determinismo guiado a través de Script de agente es el patrón recomendado para industrias reguladas donde la capacidad de auditoría de ejecución completa es un requisito de cumplimiento. **Distribución** Los flujos de trabajo de agentes que funcionan a alta densidad deben incorporar puertas de distribución o aprobación humana explícita para acciones con consecuencias irreversibles, como transacciones financieras, envíos de normativas o compromisos de proveedores. Los controles condicionales de secuencias de comandos de agentes proporcionan el mecanismo para aplicar estas puertas de forma determinista en un flujo de trabajo de otro modo agente. ## Mejores prácticas relacionadas **Priorice la sencillez en su diseño de orquestación**. Comience en el nivel de orquestación mínimo que puede alcanzar el objetivo, validarlo bajo carga real e iterar. Cada agente, traspaso o dependencia adicional en su cadena presenta una nueva superficie que puede producir un comportamiento incoherente. En su ruta de ejecución especificable, en nodos donde se requiere razonamiento, comience a incrustar un agente. Siga las mejores prácticas para la creación de Agentes en Agentforce. Evite empaquetar numerosos subagentes (anteriormente “temas”) y nunca inflar instrucciones. Los agentes implementados en casos de uso de automatización pueden permitirse ser ágiles, ya que no son la única interfaz. Seleccione la primitiva correcta para el encadenamiento. Un patrón de orquestación (delegación) tiene un control más estricto sobre la secuencia de ejecución y puede delegar subtareas en especialistas. Evite patrones coreográficos (transferencia). Si debe implementar un diseño de traspaso, proporcione al agente receptor el objetivo, el contexto y el estado de modo que pueda optimizar globalmente en vez de objetivos locales. **Evite acciones o herramientas**. Las acciones son donde se realiza el razonamiento de agentes y su diseño determina si producen resultados o fallos fiables. Cada acción debe devolver una respuesta estructurada y observable que el agente de IA puede utilizar para planificar el siguiente turno de la plática. Tener más de una acción (y diferentes construcciones de salida) para realizar la misma tarea degrada la capacidad del agente para razonar o seleccionar la herramienta correcta para el trabajo. Puede hacer que el agente pierda matices. La superposición de definiciones de acciones corre el riesgo de una clasificación errónea. Asegúrese de que su biblioteca de acciones está auditada, versionada y se ajusta al ámbito Subagente (anteriormente Tema). **Defina objetivos observables.** Defina el objetivo como un resultado observable, no solo un procedimiento. Un objetivo impreciso invita a la desviación de agentes. Aumenta con una ruta de ejecución especificable. Utilice Gráfico de agente con razonamiento híbrido para modelar el objetivo como un nodo de gráfico con estado explícito. El tiempo de ejecución realiza un seguimiento de la posición actual del agente en el flujo de trabajo y la restaura después de entradas tangenciales; no perderá el objetivo cuando reciba información adicional en la ventana de contexto. **Pruebe y evalúe**. Implemente un marco de trabajo de pruebas y evaluación sólido para validar el razonamiento de nodos probabilistas y el resultado de automatizaciones de agentes. Verifique las rutas de ejecución con respecto a una ruta de resultados prevista para asegurarse de que el modelo llega al resultado correcto. Evite fallos silenciosos donde un agente reporta falsamente éxito o entra en un bucle infinito o no recuperable afirmando los resultados en pasos de ejecución. Utilice el [rastreo de sesiones](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5) para inspeccionar interacciones paso a paso, ejecuciones del motor de razonamiento, acciones, entradas/salidas de solicitudes y pasarelas, mensajes de error y respuestas finales. ## Recursos
Agentforce Automatización tradicional Integración
**Sobre el autor** Arvind Palaniswamy es Arquitecto de Ingeniería de Software en la Oficina del Arquitecto Jefe del Equipo Bien Arquitecto. Le gusta enmarcar sistemas complejos en sus formas más sencillas utilizando los primeros principios. Comprende ingeniería, operaciones y negocios a través de décadas de experiencia y educación de MS/MBA(Kellogg). # Empezar a trabajar con guías de decisiones de integración Esta sección proporciona directrices prácticas para elegir las herramientas y enfoques de integración de datos correctos para Salesforce. Cubre integraciones salientes, integraciones entrantes y escenarios entre organizaciones, ayudando a los arquitectos a diseñar e implementar integraciones de capa de datos que equilibran desempeño, capacidad de mantenimiento y costo. --- ## Integración de datos con Salesforce La [integración de datos con Salesforce](/docs/architect/es-mx/decision-guides/guide/data-integration) proporciona una descripción general integral de las herramientas de integración de datos de Salesforce y las mejores prácticas: - **Paisaje de herramientas de integración**: Descripción general de herramientas de integración de datos de Salesforce, incluyendo opciones de código bajo, híbridas y pro-código, con directrices sobre la selección de la herramienta correcta para casos de uso específicos. - **Integraciones salientes**: Métodos para enviar datos desde Salesforce a sistemas externos, incluyendo Captura de datos de cambios, Servicios externos, Heroku Connect, Procedimientos de integración de OmniStudio, Salesforce Connect, MuleSoft Anypoint y soluciones Apex personalizadas. - **Integraciones entrantes**: Enfoques para incorporar datos externos en Salesforce, con directrices sobre la replicación de datos frente a la virtualización y cuándo utilizar cada herramienta. - **Integraciones entre organizaciones**: Métodos recomendados para compartir datos entre organizaciones de Salesforce, incluyendo MuleSoft Anypoint, Heroku Connect, API de Salesforce nativas, Captura de datos de cambios y Salesforce Connect con adaptador entre organizaciones, incluyendo directrices para sustituir implementaciones heredadas de Salesforce a Salesforce. - **Marco de decisiones**: Consideraciones clave para seleccionar herramientas de integración, como herramientas existentes y panorama, requisitos de flujo de datos (temporización, direccionalidad, experiencia de usuario esperada), complejidad de implementación, capacidad de mantenimiento, volumen de datos y límites de plataforma. Permite a los arquitectos elegir las herramientas y los patrones de integración correctos para cada escenario, minimizando la replicación de datos innecesaria, aprovechando las soluciones ESB/ETL existentes y garantizando integraciones ampliables y mantenibles que se alinean con los principios de la arquitectura de la compañía. # Empezar a trabajar con guías de decisiones de plataforma Esta sección proporciona orientación práctica para tomar decisiones arquitectónicas críticas acerca de funciones de Salesforce Platform. Cubre el procesamiento asíncrono, los eventos desencadenados por registros, la creación de formularios, la automatización de flujos de trabajo tradicionales y agentes, la arquitectura dirigida por eventos y los marcos de trabajo asíncronos basados en pasos para ayudar a los arquitectos a diseñar soluciones de plataforma ampliables, mantenibles y de alto desempeño. --- ## Procesamiento asíncrono [Procesamiento asíncrono](/docs/architect/es-mx/decision-guides/guide/async-processing) proporciona directrices sobre herramientas y enfoques para operaciones asíncronas en Salesforce: - **Herramientas de procesamiento asíncrono**: Comparación de Apex colocable en cola, Apex programado, Desencadenadores de eventos de plataforma, Captura de datos de cambios, Ruta programada (Flujos después de confirmar) y Ruta asíncrona (Flujos desencadenados por registro), con directrices sobre casos de uso apropiados. - **Procesamiento asíncrono del lado del servidor**: Patrones para operaciones de base de datos de larga ejecución, llamadas externas y procesamiento de registros de gran volumen. - **Procesamiento asíncrono del lado del cliente**: Técnicas como Llamadas de continuación Apex y procesamiento asíncrono del lado del cliente que se pueden ejecutar en navegadores o aplicaciones móviles. - **Marco de decisiones**: Considere la validación de casos de uso, la capacidad de ampliación, la comprensión de cuándo las transacciones son verdaderamente asíncronas, el monitoreo y la gestión de eventos de carga extrema. - **Mejores prácticas y antipatrones**: Directrices para un uso adecuado, incluyendo integraciones salientes, monitoreo y evitando riesgos comunes. Permite a los arquitectos implementar patrones asíncronos ampliables, fiables y mantenibles, evitando riesgos que comprometen el desempeño. --- ## Formularios de construcción [La creación de formularios](/docs/architect/es-mx/decision-guides/guide/build-forms) guía a los arquitectos sobre las opciones de creación de formularios de Salesforce: - **Herramientas de creación de formularios**: Comparación de Formularios dinámicos, Flujo de pantalla, OmniStudio, Flujo de pantalla con componentes web Lightning (LWC) y LWC, incluyendo consideraciones de habilidades y licencias. - **Marco de decisiones**: Tenga en cuenta la repercusión de los objetos, el ámbito de los formularios, la navegación, la ubicación (aplicación, móvil, web), el UX y la automatización de pruebas. - **Orientación de selección**: de herramientas Recomendaciones desde formatos de registro sencillos a asistentes de múltiples páginas y formularios con marca de cara al cliente. - **Patrones de combinación**: Directrices para combinar herramientas, por ejemplo, navegación de flujo de pantalla con estilo LWC. - **Funciones avanzadas**: Profundice en funciones y limitaciones para informar la elección de herramientas. Ayuda a los arquitectos a seleccionar el enfoque de creación de formularios correcto para sus requisitos específicos de UX, funcionales y de integración. --- ## Determinación de la automatización de flujos de trabajo agentes y tradicionales [Determinar la automatización de](/docs/architect/es-mx/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) flujos de trabajo agentes y tradicionales proporciona un marco para elegir entre automatización tradicional y Agentforce utilizando el marco Densidad de orquestación: - **Marco de densidad de orquestaciones**: Evalúa la complejidad de la automatización basándose en la ruta de ejecución (completamente especificable frente a no especificable), la complejidad de objetivos (tarea única frente a objetivos competidores) y la combinación de modalidades (entradas estructuradas frente a multimodales). - **Paisaje de productos**: Comparación de flujos, Apex, Agentforce, Agent Script, Agentforce Grid, Agentforce Operations y MuleSoft para diferentes escenarios de automatización. - **Matricial de selección de densidad**: Asigne niveles de densidad de orquestación (bajo, medio, alto) a estándares arquitectónicos, desde la automatización desencadenada por registro a la orquestación híbrida al determinismo guiado con Script de agente. - **Marco de decisiones**: Proceso de evaluación secuencial (inspeccione la ruta de ejecución primero, luego la complejidad del objetivo y luego la combinación de modalidades) para determinar la herramienta correcta. - **Utilizar directrices de casos**: Recomendaciones específicas para automatización tradicional (basada en reglas, determinista), Agentforce Grid (tareas de IA masiva), orquestación híbrida (procesos complejos de extremo a extremo) y Script de agente (puntos de entrada no estructurados con necesidades de razonamiento). Permite a los arquitectos tomar decisiones fundamentadas en todo el espectro de automatización, equilibrando las funciones de razonamiento con el control determinista para soluciones ampliables, auditables y mantenibles. --- ## Arquitectura dirigida por eventos [Arquitectura dirigida por](/docs/architect/es-mx/decision-guides/guide/event-driven) eventos proporciona una guía integral de patrones y herramientas de eventos de Salesforce: - **Herramientas de eventos**: Descripción general de eventos de plataforma, Captura de datos de cambios, API Pub/Sub, MuleSoft Anypoint, API de transmisión y consideraciones de integración. - **Patrones dirigidos por eventos**: Incluye patrones de publicación/suscripción, fanout, mensajes pasados, transmisión y cola para varios casos de uso dirigidos por eventos. - **Integración con MuleSoft**: Uso de conectores Anypoint (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) para arquitecturas de negocio. - **Eventos de plataforma y Captura de datos de cambios**: Directrices sobre mecanismos preferidos para publicar cambios de registro y campo, con migración desde PushTopic/Eventos genéricos. - **Patrones de implementación**: Mejores prácticas para la capacidad de ampliación, la coherencia, la gestión de errores y el monitoreo. Permite a los arquitectos diseñar sistemas escalables dirigidos por eventos casi en tiempo real que conectan múltiples sistemas de forma eficiente. --- ## Marco de trabajo asíncrono basado en pasos [Marco asíncrono basado en](/docs/architect/es-mx/decision-guides/guide/step-based-async-framework) pasos proporciona un marco para el procesamiento de trabajos asíncronos modular y ampliable: - **Arquitectura de marco**: Los componentes incluyen Apex colocable en cola, Finalizadores, Flujo programado, Cursores Apex, Acciones invocables e integraciones de Slack. - **Procesamiento basado en pasos**: Divide el trabajo en pasos independientes que pueden ejecutarse, reintentarse y reiniciarse con una gobernanza compartida y visibilidad operativa. - **Orientación de implementación**: Interfaz Patrones para paso, Procesador de pasos, Capa invocable Apex, gestión de retrasos y notificaciones. - **Mejores prácticas**: Recomendado cuando la mayoría de la información existe en CRM, para cargas de trabajo de gran volumen y procesamiento de registros jerárquicos o basados en árboles; directrices sobre cuándo no utilizar. - **Funciones de nivel de compañía**: Gobernanza, cumplimiento, estado distribuido, seguimiento de progreso, monitoreo de SLA, diagnóstico de fallos y registro a nivel de auditoría. Proporciona a los arquitectos una alternativa ampliable a trabajos por lotes monolíticos y llamadas asíncronas encadenadas, admitiendo cargas de trabajo de Salesforce de gran volumen con transparencia operativa completa. --- ## Automatización desencadenada por registro [Automatización desencadenada por](/docs/architect/es-mx/decision-guides/guide/record-triggered) registros proporciona el marco de trabajo para diseñar la automatización desencadenada por registros en Salesforce Platform: - **Selección de herramientas**: Cuándo utilizar desencadenadores Flujo desencadenado por registro frente a Apex, guiados por la densidad de automatización (baja, media, alta) y la matriz de selección de densidad. - **Densidad de automatización**: Cómo evaluar la cantidad de automatización, el volumen de registro y la expansión de la dependencia para elegir desencadenadores Flujo, híbrido (Flujo con Apex invocable) o Apex. - **Puntos de entrada y gobernanza**: Un punto de entrada por objeto de Salesforce; directrices sobre condiciones de entrada, control de recursión y ejecución ordenada. - **Invocación asíncrona**: Cuándo y cómo invocar procesos asíncronos desde flujos desencadenados por registros o Apex, con precaución sobre el tratamiento de errores y los límites reguladores. - **Mejores prácticas**: Patrones para la masificación, el diseño híbrido de Apex y evitar riesgos comunes en la automatización de desencadenadores. Permite a los arquitectos diseñar automatizaciones desencadenadas por registros ampliables, mantenibles y con desempeño alineadas con estándares de plataforma. # Formularios de construcción Existen múltiples opciones para la creación de formularios en Agentforce 360 Platform, y abarcan un continuo desde enfoques de código bajo a pro-código. En un extremo del continuo, Formularios dinámicos en Lightning App Builder y flujos de pantalla en Flow Builder se pueden utilizar para soluciones de código bajo. Por otro lado, el marco de trabajo Componente web Lightning (LWC) se utiliza para soluciones de procódigo. Dentro del continuo, las herramientas se pueden combinar de varias formas utilizando flujos de pantalla ampliados por LWC y formularios de cara al cliente que se crean utilizando OmniStudio. ## Descripción general de guía Esta guía presenta un marco de decisiones y directrices sobre la creación de formularios para soluciones de interfaz de usuario. Específicamente, utiliza una docena de puntos de decisión de tiempo de ejecución y no funcionales para seleccionar correctamente la mejor tecnología para un caso de uso concreto. ## Comida para llevar - **Cuando cree/modifique/vea formatos para páginas Lightning, utilice Formularios dinámicos.** En adelante, recomendamos utilizar _Formularios dinámicos_ en _Lightning App Builder_ para configurar páginas de detalles de registros. - **Si necesita crear, crear o modificar un formulario para un objeto, utilice _Lightning Pages_ y _Dynamic Forms_.** Esta es la forma más sencilla de crear formularios en Agentforce 360 Platform. También proporciona funciones adicionales (por ejemplo, control de visibilidad de campo). - **Si está creando un formulario de varias páginas o un asistente y no tiene requisitos estrictos de marca o UX, utilice un Flujo de pantalla.** Los flujos de pantalla proporcionan un marco de trabajo de navegación lineal para orquestar múltiples formularios. Puede utilizar LWC para construir su propio marco de trabajo para navegar entre formularios, pero recomendamos permitir que Flow haga el trabajo de modo que pueda centrarse en los formularios en sí en vez de centrarse en el estado del formulario. - **Si necesita lógica o acciones adicionales para admitir el formulario, utilice un Flujo de pantalla, OmniStudio o LWC.** Cada una de estas herramientas ofrece diferentes formas de mejorar su solución permitiéndole ampliarse más allá de la creación o modificación de un único registro. En esta instancia, el término _más_ puede hacer referencia a lógica avanzada (por ejemplo, bifurcación o iteración), o puede hacer referencia a acciones como la integración con sistemas externos, el envío de emails o el envío de notificaciones a la aplicación móvil de un usuario. - **Si tiene requisitos de UX sofisticados o si necesita gestionar de forma dinámica más de visibilidad de la interfaz de usuario, utilice LWC u OmniScript.** Para requisitos que se pueden cumplir utilizando formatos basados en tema y columna, puede crear sus formularios directamente en un generador de código bajo. Sin embargo, el control granular sobre el estilo de su formulario requiere la flexibilidad de LWC. Si es un cliente de Industries (y necesita una marca perfecta para los píxeles o tiene datos jerárquicos complejos), utilice Omnistudio, que le permite crear formularios de nivel de consumidor que pueden gestionar transformaciones de datos y lógica de negocio complejas. - **Si necesita implementar la automatización de pruebas, utilice LWC.** Puede redactar pruebas de unidad para cualquier LWC, independientemente de dónde lo integre. Esto proporciona la capacidad de crear una estrategia de prueba más sólida, que puede incluir pruebas masivas con múltiples registros, así como pruebas negativas. - **No está obligado por “cualquiera/o” decisiones.** Puede combinar múltiples opciones para alcanzar la mejor solución para sus casos de uso (por ejemplo, si necesita el sistema de navegación integrado de Flow y la flexibilidad de estilo completa que ofrece LWC, puede utilizarlas conjuntamente). ## Herramientas en ámbito Las siguientes herramientas se utilizan habitualmente para implementar y ampliar experiencias de formulario. ### Descripciones de herramientas
Formularios dinámicos Formularios dinámicos en Salesforce Lightning App Builder desglosa componentes Detalle de registro monolíticos en secciones y campos configurables individuales. Esta función permite a los administradores crear páginas flexibles y de alto desempeño colocando campos en cualquier parte y utilizando reglas de visibilidad para mostrar u ocultar componentes basándose en perfil de usuario, dispositivo o datos, lo que ayuda a reducir la aglomeración de páginas.
Flujo de pantalla Un Flujo de pantalla de Salesforce es una herramienta de automatización interactiva dentro de Flow Builder que requiere la entrada del usuario para pasar por procesos de negocio personalizados paso a paso. A diferencia de los flujos en segundo plano automatizados, los flujos de pantalla proporcionan una interfaz de usuario similar a la del asistente para recopilar datos, mostrar información o realizar acciones a través de Páginas Lightning, botones o aplicaciones personalizadas sin escribir código.
Omnistudio Salesforce Omnistudio es un conjunto de herramientas de código bajo diseñado para crear rápidamente experiencias digitales guiadas específicas de la industria y procesos de negocio complejos. Permite a los desarrolladores crear interfaces de usuario perfectas para píxeles (por ejemplo, flujos de trabajo guiados y tableros dinámicos) utilizando componentes de arrastrar y soltar como Flexcards y OmniScripts. Con OmniStudio, puede crear LWC de forma declarativa.
Componentes web Lightning Componentes web Lightning de Salesforce son elementos HTML personalizados ligeros que se crean utilizando HTML, CSS y JavaScript moderno, y están diseñados para ejecutarse de forma nativa en navegadores para un desempeño superior de la interfaz de usuario de Salesforce. Permiten a los desarrolladores crear interfaces de usuario personalizadas que coexisten con componentes Aura, lo que aumenta el desarrollo a través de estándares de la industria y un ecosistema de componentes detallado.
### Conjuntos de herramientas y requisitos de licencia Esta tabla describe las herramientas disponibles para la creación de formularios a través de Salesforce, junto con sus habilidades requeridas y consideraciones de licencia. **Nota:** Profundizaremos en las funciones específicas compatibles con cada herramienta, cómo elegir entre herramientas basadas en clics y herramientas basadas en código, y cuándo combinarlas en una sección posterior.
Configuración Requisitos de licencia adicionales
Formularios dinámicos Código bajo Ninguna
Flujo de pantalla Código bajo Ninguna
Omnistudio Código bajo + Código profesional Paquete Industries
Flujo de pantalla más componentes web Lightning Código bajo + Código profesional Ninguna
Componentes web Lightning Código Pro Ninguna
## Puntos de decisión Existen varios puntos de decisión a tener en cuenta cuando realice selecciones de productos y herramientas. Esta tabla describe varios puntos de decisión y proporciona directrices de alto nivel.
Punto de decisión Directrices
Categorías de casos de uso de tiempo de ejecución
Ámbito de formulario y navegación Determine si todos los campos de su formulario se ajustarán lógicamente a una única pantalla o si los usuarios necesitan poder navegar entre múltiples pantallas.
Ubicación Identifique la(s) ubicación(es) donde desea incrustar el formulario, que puede ir desde una aplicación de Salesforce hasta una aplicación móvil y un sitio web externo.
Controlador Identifique las acciones o la lógica que se deben realizar en segundo plano mientras los usuarios interactúan con su formulario, incluyendo transformaciones de datos e integraciones con sistemas externos.
Validación Determine si tiene requisitos de validación de entrada adicionales que vayan más allá de la validación a nivel del sistema estándar que proporciona Salesforce.
Diseño de interacciones Identifique los tipos de interacciones o condiciones que deben desencadenar respuestas dinámicas en su formulario.
Estilo Determine el nivel de sofisticación necesario para su estilo y requisitos CSS deseados.
Formato Identifique los requisitos de formato de su formulario (por ejemplo, el número requerido de columnas, fichas y acordeones) y la capacidad de mostrar bloques de datos repetitivos.
Traducción Determine si su formulario debe estar traducido para otros idiomas.
Consideraciones no funcionales
Seguridad Determine si su formulario debe comprobar el acceso del usuario antes de realizar ciertas operaciones, si desea controlar quién puede acceder al formulario y si desea controlar dónde se puede incrustar el formulario.
Repercusión de objeto Determine si su formulario operará contra un único objeto o contra múltiples objetos.
Automatización de pruebas de interfaz de usuario Determine si sus procesos de DevOps requieren que su formulario se someta a pruebas de unidad automatizadas o pruebas de extremo a extremo automatizadas.
Métricas Identifique cómo le gustaría realizar un seguimiento del uso de su formulario, incluyendo vistas de página, cantidad de tiempo empleado en el formulario, índices de realización y índices de éxito.
Empaquetado e implementación Determine cómo desea distribuir o implementar su formulario después de su creación.
**Nota:** En tablas de comparación de decisiones posteriores, hay un puñado de valores asociados con cualquier par de funciones de herramientas: - **Disponible:** La herramienta/función funciona con consideraciones básicas. - **No disponible:** No hay planes para agregar asistencia en los próximos doce meses. - **No es ideal:** Esta herramienta/función puede funcionar, pero no es la herramienta óptima. - **No aplicable:** La herramienta no se aplica al caso de uso concreto. ## Casos de uso Utilice estos escenarios para comparar opciones de herramientas basadas en ámbito, UX y necesidades operativas. ### Ámbito y navegación de formularios Si puede obtener todas sus entradas de usuario desde un formulario de pantalla única, comience con Formularios dinámicos. Recuerde que Formularios dinámicos en páginas de registro pueden utilizar la función Ruta para dar cobertura a procesos de negocio por etapas. #### Preguntas para formular - ¿Necesita una sola pantalla o el usuario tendrá que navegar entre múltiples pantallas para completar una tarea? - ¿Desea que sus usuarios vean una representación visual de lo avanzado que están en el proceso al rellenar su formulario? ¿Se requerirá que sus usuarios rellenen la información de cada pantalla en un orden específico, o deben poder moverse de un lado a otro entre pantallas según sea necesario? Si necesita más funciones de las que ofrece Formularios dinámicos, la elección entre Flujo, OmniStudio y LWC depende de algunas preguntas adicionales: - ¿Está bien mostrar una barra de navegación en la parte inferior de su formulario? Si la experiencia de navegación de Flujo de pantalla y OmniScript proporciona una UX no deseada, inclínese hacia LWC. - ¿Qué debe ocurrir detrás del formulario? Si necesita que un administrador pueda configurar el comportamiento, utilice un Flujo. Para relaciones complejas de múltiples objetos, utilice _OmniScript_ o _LWC_.
Pantalla única Formulario de múltiples pantallas Indicadores de progreso Saltar la navegación entre pasos/pantallas
Formularios dinámicos Disponible No disponible Disponible No disponible
Flujo de pantalla Disponible Disponible Disponible No disponible
Omnistudio Disponible Disponible Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible
LWC Disponible No es ideal No es ideal No es ideal
Si selecciona Flujo u OmniStudio, es posible que también necesite crear un LWC para alcanzar la UX correcta. Si ya está creando un LWC para diseñar su formulario correctamente, considere si es necesario [integrar ese componente en un flujo](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow). **Navegación de estilo asistente** Por otro lado, si su solución tiene el aspecto de un asistente (donde el usuario navega entre múltiples pantallas), considere Flow u OmniStudio. Flujos y OmniStudio incluyen un modelo de navegación integrado, de modo que no tiene que crear y mantener LWC que están encadenados juntos. La navegación es lineal, con acciones de avance, acciones de retroceso y un mecanismo para guardar el formulario para más adelante. También puede crear un formulario con navegación no lineal si se ajusta a sus fines. OmniStudio ofrece una ventaja de navegación clave proporcionando indicadores de progreso desde la navegación estándar que afloran pasos en el formulario. La vista de paso muestra automáticamente dónde está un usuario en un formulario de múltiples pasos. A diferencia de Flujo, permite a los usuarios saltar entre pantallas haciendo clic en varios pasos en todo el formulario. Independientemente de que esté creando formularios de pantalla única o múltiples pantallas, es importante asegurarse de que sus formularios se simplifican de modo que sean fáciles de navegar para sus usuarios. ### Factor de forma Si está incrustando un formulario en una página de registro Lightning estándar, cualquiera de las herramientas que estamos comparando funcionará. Sin embargo, Formularios dinámicos solo están disponibles en estos momentos en el escritorio. Si desea proporcionar una experiencia que permita a los usuarios acceder a formularios desde otras ubicaciones, es posible que tenga que considerar opciones alternativas. #### Preguntas para formular - ¿Necesitarán los usuarios acceder al formulario a través de escritorio, móvil o ambos? - ¿Deberían los usuarios poder acceder al formulario desde cualquier parte de su aplicación a través de una barra de utilidades? - ¿Desea activar acciones rápidas para que los usuarios puedan rellenar su formulario sin tener que abandonar la página en la que se encuentran actualmente? - ¿Necesita su formulario estar disponible en un sitio web externo?
Página de registro Lightning Página de inicio o página de aplicación Lightning Sitios de Aura Experience Cloud Sitios de LWR Experience Cloud Snap integrados Barra de utilidades Acción específica de objeto Acción global Aplicación móvil Salesforce* Field Service Mobile SDK móvil Sitios y aplicaciones externos LWC personalizado
Formularios dinámicos Disponible No disponible No disponible No disponible No disponible No disponible No disponible No disponible Disponible No disponible No disponible No disponible No disponible
Flujo de pantalla Disponible Disponible Disponible Disponible Disponible Disponible Disponible No disponible Disponible Disponible** No disponible No disponible Disponible
Omnistudio Disponible Disponible Disponible No disponible No disponible Disponible No disponible No disponible Disponible No disponible No disponible Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible Disponible Disponible No disponible Disponible No disponible No disponible No es ideal Disponible
LWC Disponible Disponible Disponible Disponible Disponible Disponible No disponible No disponible Disponible No disponible No disponible Disponible Disponible
*Flujos y LWC son compatibles con la aplicación móvil Salesforce, pero no admite todas las formas de incrustar flujos y LWC (por ejemplo, las acciones específicas de objetos son compatibles con dispositivos móviles, pero los elementos de la barra de utilidades no).

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

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

**Aunque los OmniScripts no pueden tener un conjunto especificado de ubicaciones de destino, las FlexCards sí.
#### Elevar permisos de usuario Cuando un programa se ejecuta en **contexto de usuario**, Salesforce aplica una serie de comprobaciones de acceso, que incluyen la verificación de la seguridad a nivel de campo, los permisos CRUD y el acceso a registros basándose en las reglas de colaboración de su organización (por ejemplo, los usuarios solo podrían ejecutar un formulario de actualización de casos si tienen la capacidad de actualizar casos, la seguridad a nivel de campo apropiada y el acceso al registro en cuestión). ¿Qué sucede si desea que los usuarios puedan realizar una operación concreta cuando están utilizando su formulario, pero no a través de ningún otro formulario o interacción? ¡Ahí es donde entra **el Contexto del sistema**! **Contexto del sistema** le permite elevar los permisos de un usuario durante la sesión (por ejemplo, el usuario no necesita actualizar el acceso al objeto Caso para completar correctamente su formulario de actualización de casos). Esto es especialmente útil para comunidades no autenticadas. En vez de otorgar a los usuarios invitados habilidades potencialmente peligrosas, establezca su formulario para ejecutarse en contexto del sistema. Contexto del sistema solo debe utilizarse cuando sea absolutamente necesario. Cuando se ejecuta un formulario en Contexto del sistema, cada operación CRUD omite los componentes de colaboración y seguridad a nivel de objeto y campo. Del mismo modo, Contexto del sistema no influye en quién considera Salesforce como el _actor_ (el nombre que ve en el campo **Última modificación por**). Para cada operación que realice su formulario (por ejemplo, una actualización de caso), el _actor_ es el usuario actual (incluso si el formulario se ejecuta en un contexto diferente). **Nota:** Formularios dinámicos, OmniScripts y LWC siempre se ejecutan en contexto de usuario, y no hay forma de sustituir este comportamiento. Los flujos de pantalla se ejecutan en contexto de usuario de forma predeterminada, pero puede establecerlos para que se ejecuten en contexto del sistema. Puede decidir si el flujo debe otorgar acceso a todos los datos o si debe aplicar acceso a nivel de registro. - Si incrusta un componente Lightning en un flujo que se ejecuta en contexto del sistema, el flujo no sustituirá el contexto del componente. Si necesita omitir las comprobaciones de acceso de usuarios, utilice el flujo para realizar esas operaciones y pasar los datos apropiados dentro o fuera del componente Lightning. Algunos componentes listos para su uso (por ejemplo, Búsqueda) no pueden operar dentro del contexto del sistema. - Si su flujo llama acciones Apex, se implican otros matices. - Si la clase Apex está establecida como _colaboración heredada_, se ejecutará en contexto del sistema con colaboración independientemente de cómo esté establecido el flujo. - Si la clase no tiene ninguna declaración de colaboración explícita, se ejecutará en contexto del sistema sin colaboración independientemente de cómo se establezca el flujo. - Si la clase está establecida como _con colaboración o sin_ colaboración, sustituirá el contexto del flujo. **Consultar registros en contexto del sistema con sitios de Experience Cloud** Si está ejecutando un flujo en contexto del sistema en un sitio de Experience Cloud (especialmente si no está autenticado), almacene solo campos específicos en sus elementos **Obtener registros**. Cuando está trabajando con Flow y pasa los resultados de un elemento **Obtener registros** a un flujo secundario, una acción invocable o un componente Lightning, es posible que las herramientas de desarrollador del navegador inspeccionen todos los campos de ese objeto. A pesar de sus intenciones, esto puede hacer que los campos estén disponibles para usuarios de Experience Cloud. Para asegurarse de que solo se exponen los campos correctos cuando se activa Contexto del sistema, especifique esos campos específicos en sus elementos **Obtener registros**. **Nota:** La lógica de OmniScript se ejecuta en el lado del cliente, lo que permite a los atacantes modificar la ejecución esperada de un OmniScript y ver respuestas a Procedimientos de integración, Asignadores de datos y llamadas de métodos Apex a través de las herramientas de desarrollador del navegador. Cuando está utilizando OmniScript, es importante ejecutar lógica de negocio en el lado del servidor (cuando sea posible) e implementar reglas de validación de entrada para cualquier método Apex expuesto a través de una [anotación @InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5). **Depurar entradas** Para proteger su organización de malos actores, utilice la desinfección de entrada. Supongamos que tiene una entrada en un formulario accesible públicamente que se puede asignar a un campo **Texto enriquecido** en su organización. Es posible que desee considerar activar la automatización que elimina cualquier HTML que pueda ocultar direcciones URL maliciosas. No es ideal implementar la desinfección a nivel de formulario porque puede tener cualquier número de orígenes que escriban en estos campos. Para ayudar a combatir este problema, cree un Flujo de actualización de **campo rápida (Antes de guardar)** o utilice un **Desencadenador Apex** existente para eliminar o modificar cualquier HTML potencial que pueda ingresarse en el formulario. #### Mejores prácticas - Permita que los flujos se ejecuten en su contexto predeterminado (a menos que necesite elevar el acceso del usuario actual para una operación específica). - Evite ejecutar flujos en contexto del sistema para usuarios invitados. Cree conjuntos de permisos con acceso de campo limitado y asígnelos al perfil de usuario invitado de Experience Cloud. - Al consultar registros en Contexto del sistema Ejecutar flujos en sitios de Experience Cloud, almacene únicamente los campos que necesita en el elemento **Obtener registros** o **Acciones invocables**. - Si un flujo realiza una variedad de operaciones, todas las cuales no requieren acceso elevado, utilice Subflujos para aislar las operaciones que deben ejecutarse en Contexto del sistema. - Si está incrustando un formulario en una página web externa, es posible que tenga que asignarse a campos de **Texto enriquecido** para ayudar a evitar posibles ataques de phishing. Para ello, depure las entradas de usuario para eliminar HTML utilizando un **Flujo de actualización** de campos rápida o **Desencadenador Apex**. #### Notas adicionales - OmniScripts, FlexCards y LWC se ejecutan en contexto de usuario de forma predeterminada. - Los LWC se ejecutan en contexto de usuario de forma predeterminada. - Los flujos se ejecutan en contexto de usuario, pero puede sustituirlos utilizando un controlador Apex. - Las operaciones que se realizan en la API de la interfaz de usuario se ejecutan en contexto de usuario. - Las operaciones que se realizan con un controlador Apex dependen de la clase específica. Para realizar estas operaciones en modo sistema, establezca la **clase Apex** en with sharing o without sharing. #### Control de acceso Si necesita controlar quién puede acceder a un formulario, revise el contenedor donde está incrustado el formulario (por ejemplo, puede asignar páginas Lightning para que estén disponibles para aplicaciones, tipos de registro o perfiles concretos). Si ciertas entradas son confidenciales, utilice reglas de visibilidad para controlar aún más lo que se muestra a quién. Esta función se aplica a Formularios dinámicos y Flujos de pantalla. Puede [restringir un Flujo](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) a perfiles o conjuntos de permisos concretos (similar a la clase Apex o páginas Visualforce). Los flujos no están restringidos de forma predeterminada, lo que significa que cualquier usuario con el permiso de usuario **Ejecutar flujos** puede acceder a ellos. Si está utilizando OmniStudio, puede configurar un [comprobador de permisos](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) de clase Apex que requiere que los usuarios tengan acceso explícito a la clase Apex que administra acciones remotas desde las API de OmniScript, Flexcard, Classic Card o REST. **Nota:** Las comprobaciones de permisos de clases Apex solo se aplican a clases Apex. También es recomendable establecer permisos a nivel de perfil para [Procedimientos de integración y Asignadores de datos](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5). #### Mejores prácticas de control de acceso - Si está exponiendo un Flujo a usuarios invitados, solo debe otorgar acceso de perfil de usuario invitado a los Flujos que necesitan absolutamente. Es posible agregar **Ejecutar flujos** a perfiles de usuario invitado; sin embargo, esta práctica puede ser riesgosa. - Tenga cuidado al trabajar con flujos que operan en Contexto del sistema. Debe restringir estos flujos a un conjunto concreto de usuarios ya que tienen menos controles y contrapesos para proteger sus datos. - Asegúrese de que cualquier OmniScript que ejecuta Apex en una comunidad de usuarios invitados tiene **la colaboración** enumerada en la definición de clase Apex. - Para perfiles de usuario invitado, solo asigne las clases Apex que desea permitir a los usuarios invitados llamar. Siguiendo esta práctica, ayuda a evitar exponer involuntariamente lógica de negocio adicional a usuarios invitados. Para LWC, puede comprobar las asignaciones de permisos del usuario actual para confirmar si tiene un permiso estándar o personalizado concreto. Puede importar permisos de Salesforce desde los módulos con ámbito de `@salesforce/userPermission` y `@salesforce/customPermission` directamente en **JavaScript**. También puede utilizar Apex para comprobar permisos. #### Integrar controles Los LWC solo están disponibles en una ubicación determinada después de agregarlos como un [destino](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) válido (por ejemplo, puede hacer que un componente esté disponible en páginas de registro y no como un elemento de barra de utilidades). Una vez activado un Flujo de pantalla, está disponible en todas las ubicaciones que admiten Flujos de pantalla. Flow Builder admite múltiples tipos de flujos que tienen pantallas. El tipo más destacado es **Flujo de pantalla**, pero existen otros tipos especializados restringidos a ubicaciones específicas (por ejemplo, la **aplicación Field Service Mobile** solo admite **Flujos Field Service Mobile)**. Esto es similar a **Flujos de solicitud** de contacto, que solo se admiten en Experience Cloud. Independientemente del tipo de Flujo, la persona que crea el Flujo no tiene control sobre dónde está integrado el Flujo. Los flujos están disponibles en cada ubicación donde se admite ese tipo de flujo específico. Si está utilizando Salesforce Industries, hay una ligera advertencia cuando se trata de OmniScript.No puede especificar un objetivo para un OmniScript; sin embargo, puede especificar un objetivo para las FlexCards que desea integrar. ### Automatización de pruebas de la interfaz de usuario En Salesforce, existen varias herramientas de automatización de pruebas de extremo a extremo (por ejemplo, consulte [UTAM de Salesforce](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)) que le permiten simular cómo interactúa un usuario con sus formularios. Puede redactar pruebas para cualquier interfaz de usuario estándar o personalizada, incluyendo páginas Lightning y Flujos de pantalla. **Nota:** Estos tipos de pruebas no pueden verificar los resultados de los métodos que se están realizando. Tenga esto en cuenta cuando configure sus requisitos de automatización de pruebas de la interfaz de usuario. #### Preguntas para formular - ¿Necesita pruebas automatizadas para sus formularios? - ¿Qué tipos de pruebas tiene intención de realizar? - ¿Qué nivel de granularidad es necesario para las automatizaciones de pruebas?
Pruebas de unidad Automatización de extremo a extremo
Formularios dinámicos No disponible Disponible*
Flujo de pantalla No disponible Disponible*
Omnistudio Disponible* Disponible*
Flujo de pantalla + LWC Disponible* Disponible*
LWC Disponible Disponible
*Requiere código
**Considerar requisitos de automatización de pruebas de interfaz de usuario** Las **pruebas de unidades** proporcionan una automatización y validación granulares que se alinean con herramientas y sistemas de CI/CD estándar de la industria, que prueban la lógica de negocio, los controles de JavaScript y los resultados de componentes específicos. Si elige un enfoque de código bajo, no podrá realizar pruebas de autoría; sin embargo, Salesforce prueba rigurosamente todas las ofertas de extremo a extremo. Si los métodos de su componente son complejos, puede enviarlos por mensaje de texto individualmente colocando los métodos en archivos JavaScript exclusivos. Esto le permite importarlos en un LWC y luego en una **prueba Jest (por ejemplo**, importar { sort } desde 'c/utils';). Puede utilizar una solución sin código desde un ISV, crear una solución de automatización de pruebas personalizada o utilizar un marco de trabajo de prueba de código abierto (por ejemplo, Selenium WebDriver o WebdriverIO) para la automatización de extremo a extremo. Estas soluciones son válidas para todas las interacciones de la interfaz de usuario de Salesforce (por ejemplo, un Formulario dinámico en una página Lightning, un Flujo de pantalla en una barra de utilidades o un LWC en un Flujo de acción rápida). ### Mediciones Después de implementar su formulario en un entorno de producción, debe asegurarse de que se está utilizando de forma efectiva. Dependiendo de su caso de uso, esto puede significar realizar un seguimiento del número de veces que se completó su formulario hasta la cantidad de tiempo que el usuario medio emplea en completar el formulario antes de enviar su información. Es importante identificar sus KPI con capacidad de seguimiento antes de seleccionar una herramienta. #### Preguntas para formular - ¿Necesita realizar un seguimiento del uso de formularios? - ¿Qué indicadores clave de desempeño pueden determinar si el formulario se está utilizando de forma efectiva?
Vistas de página Tiempo empleado en el formulario Realizar seguimiento de la cumplimentación de formularios Realizar un seguimiento del índice de éxito
Formularios dinámicos Disponible** No disponible No disponible No disponible
Flujo de pantalla Disponible Disponible* Disponible Disponible
Omnistudio Disponible Disponible* Disponible Disponible
Flujo de pantalla + LWC Disponible Disponible* Disponible Disponible
LWC Disponible** Disponible* Disponible Disponible
*Disponible cuando Tiempo de ejecución de OmniStudio basado en paquetes está activado** Disponible realizando un seguimiento del uso de la página Lightning principal
Si necesita realizar un seguimiento del uso y la adopción de formularios en general, utilice herramientas de código bajo. Los flujos de pantalla y formularios dinámicos son rastreables a través de reportes personalizados listos para su uso. Sin embargo, los reportes de seguimiento de Flujo de pantalla proporcionan granularidad adicional. Si necesita realizar un seguimiento del uso de LWC, la disponibilidad de uso inmediato depende de dónde esté utilizando el LWC. Si está en una página Lightning, todos los elementos de seguimiento de uso de página Lightning disponibles también se aplican a su LWC. Esto también es cierto para LWC incrustados en flujos. Los Formularios dinámicos no tienen capacidad de seguimiento de uso inmediato; sin embargo, puede realizar un seguimiento del uso de la página Lightning principal a través de [objetos de uso Lightning](https://help.salesforce.com/articleView?id=lex_usage_reports.htm). Para realizar un seguimiento de páginas Lightning estándar, utilice el reporte personalizado **Usuarios con Lightning Usage by Page Metrics**. Para páginas Lightning personalizadas, utilice el reporte personalizado **Usuarios con Lightning Usage by FlexiPage Metrics**. Los flujos pueden ayudarle a realizar un seguimiento de la adopción de formularios específicos. Utilice el reporte de flujo de **muestra: Flujos** de pantalla para responder a estos tipos de preguntas: - ¿Cuál es el índice de realización de este formulario? ¿Está actualmente bien adoptado? - ¿Cuánto tardan los usuarios en rellenar este formulario? - ¿Qué pantalla emplean los usuarios más tiempo en completar? - ¿Con qué frecuencia navegan los usuarios a pantallas anteriores? - ¿Con qué frecuencia se producen errores? Si el reporte estándar no cumple sus necesidades, puede duplicarlo y realizar cambios o Build Your Own Report desde cero utilizando el reporte **Flujos de pantalla**. Si está utilizando el tiempo de ejecución de OmniScript basado en paquetes, también puede utilizar [OmniStudio para Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). Este servicio realiza un seguimiento de todos los tipos de eventos (por ejemplo, puede realizar un seguimiento del tiempo que tarda en completar los pasos en un OmniScript, lo que ayuda a identificar mejoras en los procesos). **Nota:** No hay una opción lista para su uso para realizar un seguimiento de un LWC que no esté integrado en una página Flujo de pantalla, OmniScript o Lightning, pero puede crear una solución personalizada utilizando Apex. ### Empaquetado e implementación Es posible que esté familiarizado con el uso de conjuntos de cambios o **DevOps Center** para implementar su solución en entornos de prueba o en producción. Estas opciones de implementación admiten completamente Formularios dinámicos, Flujos y LWC. Sin embargo, OmniStudio requiere una herramienta separada, el [Sobremesa de trabajo IX](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5). #### Preguntas para formular - ¿Cómo piensa implementar el formulario? - ¿Necesita distribuir el formulario a más de una organización de Salesforce?
Paquetes gestionados de primera generación (1GP) Paquetes gestionados de segunda generación (2GP) Paquetes desbloqueados Conjuntos de cambios DevOps Center
Formularios dinámicos Disponible Disponible Disponible Disponible Disponible
Flujo de pantalla Disponible Disponible Disponible Disponible Disponible
Omnistudio No disponible No disponible No disponible No disponible* No disponible*
Flujo de pantalla + LWC Disponible Disponible Disponible Disponible Disponible
LWC Disponible Disponible Disponible Disponible Disponible
*Utilice IDX Workbench para implementar Soluciones de OmniStudio en otras organizaciones.
Si es un ISV o un socio que planea empaquetar su solución para su distribución en AppExchange, consulte Formularios dinámicos, Flujos y LWC. Recuerde que OmniStudio no admite el empaquetado. ### Navegar por el continuo de código bajo a código pro Esta guía pretende mostrarle qué funciones y niveles de personalización están disponibles a través de Formularios dinámicos, flujos de pantalla, OmniStudio y LWC. Low-Code to Pro-Code Continuum A continuación se incluye una descripción general de alto nivel. - Cuando se trata de crear formularios, LWC es la opción más sólida y personalizable, pero tiene el menor número de salvaguardas. Por eso es crucial crear sus componentes teniendo en cuenta la [seguridad](/docs/architect/es-mx/well-architected/guide/trust.html) y [la escalabilidad](/docs/architect/es-mx/well-architected/guide/reliability.html#scalability-and-capacity-planning). - Formularios dinámicos es la opción menos flexible, pero tiene muchas menos oportunidades de pasos en falso. - Flujo y OmniEstudio caen ligeramente en el medio. Son más potentes que Formularios dinámicos, pero no están a la altura del nivel LWC. Sin embargo, tienen menos barandillas que Formularios dinámicos y son más difíciles de romper que el código personalizado. Es posible que descubra que varias herramientas se ajustan a sus necesidades. Si es así, la decisión depende en última instancia de qué herramienta es la mejor para su equipo. Para obtener más información sobre aspectos adicionales a tener en cuenta, consulte estas [Guías de decisiones](/docs/architect/es-mx/decision-guides) de arquitecto. #### Preguntas para formular - Cuando compara herramientas, ¿es importante evaluar cuánta experiencia tiene su equipo con respecto a cada herramienta? - ¿Cuántos de sus desarrolladores están bien versados en LWC o JavaScript? - ¿Hay desarrolladores en su equipo que sean expertos en Flow Builder o que hayan expresado interés en aprender más? Aunque no entraremos en detalles específicos, a continuación encontrará un poco más de información sobre cómo se relacionan estas herramientas específicas con las evaluaciones que hemos cubierto hasta ahora. **Delegación de entrega** Tenga en cuenta que incluso si algunos de sus requisitos requieren LWC, no requiere que toda la solución se cree utilizando LWC. Es importante determinar cómo puede crear su solución de forma modular. Para ello, debe identificar qué piezas requieren LWC codificado y qué piezas no. Las piezas que no requieren LWC deben construirse utilizando una solución de código bajo. Cuando se trata de Flujo y LWC, existen varios componentes (por ejemplo, Componentes de pantalla reactivos y Flujo de pantalla) que pueden sincronizarse entre sí en la misma pantalla para desbloquear nuevas herramientas para arquitectos, administradores y desarrolladores. Los desarrolladores ahora pueden crear componentes modulares específicos que se pueden reutilizar en toda la organización, lo que ayuda a potenciar la productividad del equipo. Esto permite a los desarrolladores ahorrar tiempo utilizando una mezcla de componentes Flujo estándar y personalizados para lograr el dinamismo de las formas, lo que les da más tiempo para centrarse en resolver nuevos retos. Con la introducción de Componentes reactivos en Flujo, nunca ha habido un momento más apropiado para mezclar Flujo y LWC al crear formularios. **Propiedad y mantenimiento a largo plazo** Si está creando un formulario de múltiples pasos, comience con Flujo o una mezcla de Flujo y LWC. Si el equipo que está manteniendo el formulario es un equipo de código bajo, asegúrese de que la solución es lo más configurable y ampliable posible para su audiencia prevista. Para mejorar la estabilidad y la capacidad de mantenimiento, es importante organizar su solución en unidades [componibles](/docs/architect/es-mx/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity), independientemente de la herramienta que seleccione. ### Desempeño Las consideraciones de desempeño relacionadas con Formularios dinámicos, Flujos de pantalla, OmniStudio o LWC se basan en el marco de trabajo donde se alojan las tecnologías. Las tecnologías basadas en LWC tienden a superar a las basadas en Aura. Debido a varias funciones principales implementadas de forma nativa en motores web (en vez de en JavaScript a través de abstracciones de marco de trabajo), el LWC proporciona beneficios de desempeño mejorados. Por lo tanto, ¿cómo aprovechamos estos beneficios de desempeño para nuestras tecnologías de formularios en Salesforce? Echemos un vistazo más de cerca. - Formularios dinámicos (integrados en metadatos de páginas Lightning) está construido sobre una base de pila de LWC, lo que nos permite implementar varias funciones muy esperadas. Como ventaja de desempeño adicional, Formularios dinámicos utiliza la representación progresiva, lo que mejora el tiempo de carga para páginas que tienen un gran número de campos. - Los flujos de pantalla se crean sobre LWC. La mayoría de los componentes individuales listos para su uso se convirtieron ahora a LWC con la excepción de los componentes **Carga de archivos** e **Imagen**. Aunque el equipo de Flujo convirtió el cliente de tiempo de ejecución de flujo a LWC (y la mayoría de sus componentes), los clientes aún necesitan convertir sus componentes de pantalla Aura a LWC. Recuerde que Salesforce solo admite componentes LWC en el marco de trabajo **Componente reactivo** en Flujos de pantalla. Para obtener más información, consulte el módulo Trailhead [Componentes web Lightning para](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) desarrolladores Aura. Si está considerando crear un componente personalizado para un flujo de pantalla (o cualquier otro contenedor), seleccione LWC. - Existen varias versiones de OmniStudio disponibles. Si es un cliente de larga data, es posible que esté utilizando **Angular**. Animamos a todos los nuevos clientes a utilizar FlexCards y OmniScripts basados en LWC. También animamos a los clientes existentes a migrar fuera de Angular. - LWC se basa en LWC. ## Recursos
Formularios dinámicos - Dividir sus detalles de registro con formularios dinámicos
- Obtener ayuda para Lightning App Builder
Flujo de pantalla Utilizar flujos de pantalla para interactuar con usuarios
- Automatizar tareas con flujos
Omnistudio Omnistudio
- OmniScripts
- Aplicación de escritorio IDX Workbench
- Sistema de diseño Newport
Personalizar OmniScripts y Flexcards con el Sistema de diseño Newport
LWC - Componentes web Lightning
Guía del desarrollador de componentes Lightning Aura
- Componentes web Lightning para desarrolladores Aura
# Integración de datos con Salesforce Existen multitud de formas de acceder, sincronizar y compartir datos entre Salesforce y sistemas externos. Pero no todas las herramientas son adecuadas para su proyecto concreto. Esta guía le guiará por el panorama de las herramientas de integración de datos disponibles en Salesforce. También ofrece recomendaciones para las herramientas (o combinaciones de herramientas) más apropiadas en un caso de uso concreto, así como directrices sobre herramientas a evitar para escenarios específicos. ## Descripción general de guía Esta guía de decisiones se centra en integraciones a nivel de datos que implican Salesforce. Específicamente, cubre los siguientes casos de uso de integración de datos: - Salesforce en sistemas externos - Sistemas externos en Salesforce - Organización de Salesforce a organización de Salesforce Estos son solo un subconjunto de los retos de integración a los que se enfrentan los arquitectos de Salesforce, por lo que planeamos agregar más guías de decisiones centradas en la integración dirigida por eventos, la creación de flujos de trabajo efectivos de cara al cliente o empleado utilizando la integración de procesos, etc. Finalmente, es importante tener en cuenta que muchas de las herramientas y enfoques descritos aquí se pueden utilizar para resolver retos de integración en la compañía en general, pero dichos usos están más allá del alcance de esta guía. ## Comida para llevar - **Evite la replicación de datos innecesaria.** A menos que los datos necesiten residir en Salesforce, considere la virtualización de datos con Salesforce Connect en su lugar. Más datos en su organización llevan en última instancia a mayores volúmenes de datos, lo que puede afectar negativamente al [desempeño](/docs/architect/es-mx/well-architected/guide/reliability.html#scalability-and-capacity-planning) y agregar deuda técnica. Si sus datos ya residen en Salesforce y los necesita en un sistema externo, evite copiarlos en un sistema externo a menos que sea absolutamente necesario. En su lugar, haga que el sistema externo acceda a los datos a través de las API de Salesforce. - **Utilice MuleSoft u otras soluciones de Enterprise Service Bus (ESB) o Extract-Transform-Load (ETL), si están disponibles y forman parte de su panorama existente.** Debido a que estas herramientas están creadas para ayudar a dar cobertura a la migración y transformación de datos, a menudo tienen potentes funciones que le permiten reutilizar integraciones en toda la compañía, mantener una gobernanza más sólida y centralizar la gestión de integraciones. En esta guía, siempre que se recomiende MuleSoft Anypoint, considere si su solución ESB/ETL existente será suficiente. - **Armonice datos de diferentes orígenes con Data 360 y Data Cloud One.** A través del modelo de datos Customer 360, la resolución de identidad, la federación de datos y otras funciones, Data 360 consolida datos de Salesforce y otros sistemas externos en una vista unificada de su cliente. Además, con [Data Cloud One](/docs/architect/es-mx/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one), los usuarios de otras organizaciones de Salesforce pueden acceder de forma segura a datos compartidos virtualmente desde Data 360 a través de espacios de datos. - Mueva datos entre organizaciones utilizando activaciones y acciones de **Data 360.** Después de ingresar datos desde diferentes organizaciones en Data 360, las [acciones y activaciones](/docs/architect/es-mx/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) de datos pueden sincronizar los datos con otra organización. Este enfoque puede ser muy útil para integraciones con organizaciones de Marketing Cloud. - Extraiga y mueva datos utilizando **MuleSoft Anypoint.** MuleSoft Anypoint se puede utilizar para extraer datos de Data 360 utilizando API de Connect y API de gráfico de datos y moverlos a otra organización de Salesforce. Sin Data 360, MuleSoft Anypoint también se puede utilizar cuando los datos necesitan moverse entre organizaciones sin replicarse en Data 360. - **Tenga cuidado si elige construir con Mensajería saliente.** Salesforce seguirá admitiendo Mensajería saliente dentro de las capacidades funcionales actuales, pero no tiene intención de realizar más inversiones en esta tecnología. - **Siempre se recomienda la licencia de usuario de integración con perfil "Solo API" para todas las integraciones.** Salesforce también recomienda utilizar Aplicaciones cliente externas (a favor de aplicaciones conectadas o inicio de sesión SOAP) como los patrones AuthN y AuthZ permitidos correctamente para todas las integraciones. ## Consideraciones comunes para la selección de herramientas de integración de datos Antes de profundizar en las herramientas de integración de datos disponibles, es importante tener en cuenta algunas consideraciones comunes al elegir una herramienta. Como es típico con la arquitectura, no hay una respuesta prescriptiva a cada reto de negocio. Si pronunció las palabras “depende” al realizar opciones de integración, estará en el lugar correcto.
Área a tener en cuenta Preguntas comunes
Herramientas y panorama existentes ¿Existe una solución ESB o ETL existente? ¿Tienen los datos implicados requisitos normativos o de cumplimiento? ¿Dónde están ubicados los sistemas que está intentando integrar (en la nube o in situ)?
Flujo de datos (Cronología, Experiencia de usuario prevista, Dirección) ¿Necesitan los datos moverse de forma síncrona, asíncrona o pueden ser por lotes/programados? ¿Se requiere replicación de datos? ¿Qué sistema debe ser la fuente de la verdad? ¿Cuál es el origen de datos? ¿Cuál es el destino de destino? ¿Se requiere la interacción del usuario? ¿Necesita el usuario ver el resultado de la integración? ¿Cuáles son las necesidades sobre la gestión de excepciones (reintentar, notificar, fallar)? ¿Qué grado de acoplamiento deben tener los sistemas?
Implementación ¿Cuál es el nivel de esfuerzo para sistemas que no son de Salesforce? ¿Qué equipos son responsables de entregar integraciones? ¿Qué herramientas prefieren utilizar?
Mantenibilidad ¿Qué equipos se espera que mantengan la integración? ¿Qué habilidades tienen actualmente? ¿Qué habilidades necesitarán en el futuro? ¿Cuál es el costo total de propiedad a lo largo del tiempo? ¿Qué importancia tiene la capacidad de probar, depurar y solucionar problemas con herramientas de código bajo o profesional?
Volumen de datos ¿Cuántos datos están implicados en la integración? ¿Trabajará con grandes volúmenes de datos (LDV)? ¿Con qué frecuencia se producirán cambios de forma masiva? ¿Qué tipo de repercusión tendrán las actualizaciones singleton? ¿Con qué frecuencia se producirán?
Límites ¿Necesitarán los datos someterse a una transformación compleja? ¿Necesitan combinarse los datos desde varios sistemas de origen? ¿Con qué frecuencia se realizará una integración por usuario? ¿Cuántos usuarios en total? ¿Planificó con antelación cargas de datos masivas (ejemplo: carga de datos inicial para una nueva instancia)?
## Comparación de productos Esta es una descripción general de alto nivel de las herramientas disponibles para la integración de datos y algunas consideraciones para empezar a evaluar cada opción. Las siguientes secciones incluyen casos de uso detallados y detalles sobre las funciones de estas herramientas.
De Salesforce a Sistema externo Del sistema externo a Salesforce Ejecución Se requiere licencia adicional
Acciones Apex Disponible Disponible Del lado del servidor No
Captura de datos Disponible No disponible Del lado del servidor No*
Apex personalizado (servicios web REST y SOAP) Disponible Disponible Del lado del servidor No
Servicios externos Disponible No disponible Del lado del servidor No
Heroku Connect Disponible Disponible Del lado del servidor Sí
Data 360 Disponible Disponible Del lado del servidor Sí
MuleSoft Anypoint Disponible Disponible Del lado del servidor Sí
API nativas de Salesforce No disponible Disponible Del lado del servidor No
OmniScript Disponible Disponible Del lado del cliente*** Sí
Procedimiento de integración de OmniStudio Disponible Disponible Del lado del servidor Sí
Mensajería saliente No es ideal No disponible Del lado del servidor No
Eventos de plataforma Disponible Disponible Del lado del servidor No**
Salesforce Connect / Objetos externos Disponible Disponible Del lado del servidor Sí
[\*Complemento requerido para casos de uso de eventos de Captura de datos de cambios de gran volumen](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm) [\*\*Complemento requerido para casos de uso de eventos de plataforma de gran volumen](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) \*\*\*Adecuado en situaciones donde está bien que la lógica de negocio se ejecute en el navegador web. Leyenda de columna: - **Disponible**: funciona bien para la mayoría de los casos de uso - **No es ideal**: posible pero considere una herramienta alternativa - **No disponible**: ningún plan de apoyo en los próximos doce meses ### Otras herramientas para mover datos dentro y fuera de Salesforce Existen otras herramientas que pueden admitir algunos aspectos de la integración de una capa de datos, pero no deben considerarse un medio principal para resolver problemas de integración. Echemos un vistazo rápido a estas herramientas ahora. Los **componentes web Lightning** se utilizan habitualmente para integraciones de procesos, pero pueden realizar llamadas utilizando funciones JavaScript, de modo que los datos podrían estar implicados en estas transacciones. **Salesforce Flow** se puede utilizar para orquestar llamadas externas con Servicios externos o Acciones Apex. Salesforce Flow por sí mismo no se considera una herramienta de integración de datos independiente. El Asistente de importación de **datos y el Cargador** de datos se pueden utilizar para sincronizar, importar y migrar datos. Aunque los comandos del Cargador de datos también se pueden crear secuencias de comandos para automatizar la importación y exportación de datos, la [interfaz de línea](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) de comandos es solo para Windows y ninguna de estas herramientas es una base recomendada para una estrategia de integración de datos. En su lugar, utilícelos para complementar su estrategia de mantenimiento y administración de datos. Los comandos de datos [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) se pueden utilizar para manipular registros en su organización. Los comandos están disponibles para ayudarle a importar y exportar datos con la API masiva y la API de guardado de árboles de SObject, y realizar operaciones CRUD sencillas en registros individuales con la API de REST. Salesforce CLI por sí misma no se considera una herramienta de integración de datos independiente. **OmniStudio Data Mapper** se puede utilizar como una herramienta ETL declarativa para mover datos entre objetos de Salesforce y estructuras de datos JSON. Aunque se crea automáticamente una interfaz de REST para cada interfaz de Asignador de datos, proporcionando una forma declarativa de mover datos desde sistemas externos a objetos de Salesforce, Asignador de datos independiente no es una base recomendada para una estrategia de integración de datos. Las acciones de Asignador de datos están disponibles en Procedimientos de integración de OmniStudio. [**Dataloader.io**](http://dataloader.io/) es otra herramienta de carga de datos para Salesforce con tecnología Anypoint Platform de MuleSoft que le permite importar, exportar y eliminar cantidades ilimitadas de datos para su compañía de forma rápida y segura. Dataloader.io no es una base recomendada para una estrategia de integración de datos. ## Salesforce en sistemas externos (Integración saliente) Para integraciones salientes desde Salesforce, puede considerar diferentes tipos de herramientas: código bajo, código pro o híbrido. Las siguientes secciones proporcionan orientación para cada uno de estos tipos de herramientas y ofrecen soluciones de muestra. - [Herramientas de bajo código para integraciones salientes](#herramientas-de-código-bajo-para-integraciones-salientes-desde-salesforce) - [Herramientas híbridas para integraciones salientes](#herramientas-híbridas-para-integraciones-salientes-desde-salesforce) - [Herramientas de código profesional para integraciones salientes](#herramientas-de-procódigo-para-integraciones-salientes-desde-salesforce) ### Herramientas de código bajo para integraciones salientes desde Salesforce
Directrices Licencia Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación** Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación
Captura de datos Cuando necesita publicar cambios a nivel de registro realizados en Salesforce en un sistema externo y no necesita una carga personalizada. Requerido Async No No Sí Con herramientas de procódigo Sí Sí OAuth
Servicios externos Cuando está orquestando un proceso utilizando Flow, Apex, Einstein Bots u OmniStudio y las API del sistema externo se describen utilizando especificaciones de OpenAPI. No se requiere Sync Sí No Sí Con herramientas de procódigo No N/A Credenciales nombradas
Heroku Connect Cuando desea ampliar sus datos con sincronización bidireccional para activar aplicaciones móviles y otras en Heroku, y desea que los datos también se repliquen en Salesforce. Requerido Async Sí Sí No Con herramientas de código profesional Sí Sí, a través de Shield Connect OAuth
Procedimiento de integración de OmniStudio Cuando necesita transformar datos sin interacción del usuario y mejorar el desempeño procesando en el servidor en vez del navegador. Requerido Ambos Sí Sí Sí Compatibilidad declarativa Sí Sí Credenciales nombradas
Salesforce Connect / Objetos externos Cuando desea que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo. Los datos no se replican en Salesforce. Requerido Sync No Sí* Sí Con herramientas de procódigo y un trazador declarativo No N/A Credenciales nombradas
*Los adaptadores Odata anteriores a la versión 4.01 están sujetos a límites de llamadas. Consulte Consideraciones sobre límites de frecuencia de llamadas Odata para obtener más detalles. ** Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la API de metadatos, paquetes o conjuntos de cambios en producción.
### Caso de uso: Integración saliente utilizando herramientas de código bajo > Cuando se ganan oportunidades, se debe crear un pedido para los productos asociados en el sistema ERP o el sistema de gestión de pedidos de la compañía. **Captura de datos** Conforme se actualizan los registros de oportunidades, Captura de datos cambia publica eventos de cambio que contienen las actualizaciones de los objetos. Los eventos de cambio se consumen en el lado del cliente a través de una conexión CometD (o a través de un conector MuleSoft) y se utilizan para actualizar el sistema ERP o de gestión de pedidos del cliente. Los eventos de cambio pueden enriquecerse para incluir siempre Id. de registro externos u otros datos del objeto (como región) que se necesitan para la integración. Las transmisiones de eventos de cambio para múltiples objetos se pueden combinar en _canales_ para una suscripción simplificada y procesamiento de transmisiones (de modo que puede suscribirse y procesar una transmisión en vez de muchas). **Servicios externos** Si tiene un servicio web que admite la especificación OpenAPI 2.0 o 3.0, puede exponer las operaciones y los servicios como un Servicio externo en Salesforce. Las operaciones de API (por ejemplo, crear orden) se pueden llamar como una Acción invocable en un flujo creado con Flow Builder cuando la etapa de la oportunidad cambia a "Ganada". **Heroku Connect** Heroku Connect se utiliza habitualmente para mantener una base de datos Postgres de Heroku y Salesforce sincronizadas. Si el cliente utiliza Heroku Postgres como su establecimiento de transacciones de origen de verdad, puede sincronizar los registros y los cambios de Salesforce a Heroku Postgres utilizando Heroku Connect. Desde allí, puede utilizar Conectores de transmisión de Heroku para publicar esos cambios en Apache Kafka y enviarlos como eventos a aplicaciones descendentes, incluyendo el sistema ERP o de gestión de pedidos. **Procedimiento de integración** de OmniStudio Cuando se envía un pedido, el OmniScript que orquesta el proceso puede publicar los detalles del pedido en un conector ERP o MuleSoft. La publicación puede ejecutarse directamente por OmniScript (lado del cliente) o indirectamente a través de un Procedimiento de integración (lado del servidor). Si el sistema ERP arroja un error de validación, la interfaz de usuario de OmniScript debe notificar al usuario y, si es necesario, traducir y contextualizar el error para el usuario. **Salesforce Connect / Objetos externos** Puede crear un flujo desencadenado por registro en Salesforce que inserta un registro en los objetos externos relacionados cuando la etapa de la oportunidad cambia a "Ganada". Puesto que se trata de una [transacción mixta](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1), para evitar errores, agregue un elemento de pausa durante cero segundos entre la actualización Oportunidad y los insertos de objetos externos relacionados de modo que cierre un contexto de transacción antes de iniciar uno nuevo. ### Herramientas híbridas para integraciones salientes desde Salesforce
Directrices Licencia Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación** Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación
Acciones Apex Cuando desea automatizar llamadas a otro sistema a través de Salesforce Flow. Un desarrollador puede redactar una clase Apex que un flujo puede invocar, o puede descargar una solución preconstruida desde AppExchange. No se requiere Ambos Sí No Sí Con herramientas de procódigo No Sí Múltiples
Retransmisiones de eventos Cuando necesite enviar eventos de plataforma y eventos de Captura de datos de cambios a Amazon EventBridge desde Salesforce. Las retransmisiones de eventos solo se conectan a AWS Eventbridge No Async Sí No Sí Sí Sí Sí HTTP/1.1 con TLS
Mensajería saliente Cuando necesita enviar mensajes SOAP a través de HTTP(S) a un extremo designado con recepción garantizada cuando se desencadena por una regla de flujo de trabajo. No se requiere Async No No Sí Compatibilidad declarativa Sí Sí TLS bidireccional
Eventos de plataforma Cuando necesita una carga estructurada definida personalizada para cambios casi en tiempo real en Salesforce o un sistema externo. No requerido* Async Sí No Sí Con herramientas de procódigo Sí Sí OAuth
Salesforce Connect / Objetos externos (con adaptadores Apex personalizados) Cuando desea que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo que no puede utilizar protocolos estándar como Odata o GraphQL. Requerido Ambos Sí Sí Sí Con herramientas de procódigo No N/A Múltiples
Data 360 Cuando desea datos armonizados desde diferentes orígenes en un solo establecimiento de datos, o desea replicar sus datos en otras organizaciones de Salesforce o en otros sistemas externos. Requerido Ambos Sí Sí Sí Sí Sí Sí Múltiples
[\*Complemento](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) requerido para casos de uso de gran volumen. \*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción. ### Caso de uso: Integración saliente utilizando herramientas híbridas > Cuando se ganan oportunidades, se debe crear un pedido para los productos asociados en el sistema ERP o de gestión de pedidos de la compañía. **Acciones Apex** Un flujo desencadenado por registro basado en el estado de la oportunidad puede desencadenarse automáticamente cuando se gana una oportunidad. El flujo ejecuta una acción invocable que utiliza una llamada externa para enviar el pedido al sistema de gestión de pedidos o la solución ERP. Los envíos de gran volumen y los pedidos de múltiples sitios se gestionan mediante mecanismos de cola y lotes Apex. **Mensajería saliente** Tras [configurar la mensajería](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm) saliente, puede definir una regla de flujo de trabajo desencadenada por la actualización de oportunidad para enviar un mensaje SOAP a través de HTTP(S) a una URL de extremo especificada que aloja al oyente. El mensaje contendrá los campos especificados cuando se creó el mensaje saliente. Si la información del objeto cambia después de poner la notificación en cola, pero antes de enviarse, solo se entregará la información actualizada y los mensajes permanecerán en la cola hasta que se envíen correctamente o hasta que tengan 24 horas de antigüedad. Transcurridas 24 horas, los mensajes se eliminan de la cola. Si el sistema ERP requiere datos adicionales, puede pasar el sessionId en mensajes salientes de modo que el sistema externo pueda realizar una solicitud de devolución de llamada. **Eventos de plataforma** Puede definir un evento de plataforma que incluya la carga personalizada con los datos requeridos para crear los registros en el sistema externo. Como los eventos de plataforma no se publican automáticamente tras el cambio de registro, debe publicar el evento mediante Apex, Salesforce Flow o Process Builder cuando la etapa de la oportunidad cambia a "Ganada". Un servicio externo escucha el canal de eventos de plataforma utilizando CometD (o un conector MuleSoft) y crea los registros apropiados en el sistema externo. **Salesforce Connect / Objetos externos (con adaptadores Apex personalizados)** Una solución basada en Salesforce Connect / Objetos externos no es perfecta para un caso de uso que requiere puramente sincronización de datos. Sin embargo, esta solución puede aplicarse en casos donde los usuarios de Salesforce necesitan ver y posiblemente interactuar con datos del sistema externo, y los datos no pueden replicarse en Salesforce. Si el sistema ERP o de gestión de pedidos no admite protocolos Odata o GraphQL, el equipo de desarrollo puede utilizar el [Marco de trabajo](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) del conector Apex para redactar clases Apex que gestionan la comunicación con el sistema externo a través de un protocolo compatible. **Data 360** Una solución basada en Data 360 es perfecta para casos de uso donde necesitamos datos armonizados de diferentes orígenes en un solo almacén de datos. También se puede utilizar cuando necesitamos replicar datos desde una organización de Salesforce en múltiples organizaciones de Salesforce u otros sistemas externos utilizando Data 360 como un núcleo de datos. Cuando se gana y se actualiza una oportunidad en la organización de origen, los datos de la oportunidad se sincronizarán con Data 360, donde se pueden replicar en otros sistemas incluyendo organizaciones de Salesforce utilizando diferentes mecanismos como acciones, activaciones y API. Del mismo modo, se puede hacer referencia a una oportunidad sin replicar los datos en otras organizaciones de Salesforce utilizando Data Cloud One. Sin embargo, Data Cloud One no admite plataformas que no sean de Salesforce. ### Herramientas de procódigo para integraciones salientes desde Salesforce
Directrices Licencia Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación** Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación
Apex personalizado Cuando necesita más funciones de las disponibles en herramientas de código bajo. No se requiere Ambos Sí Sí Sí Con herramientas de procódigo No Sí* Múltiples
Servicios externos La integración desde código con API del sistema externas se describe utilizando especificaciones de OpenAPI. No se requiere Sync Sí No Sí Con herramientas de procódigo No N/A Múltiples
MuleSoft Anypoint Cuando necesita una única solución unificada de nivel de compañía para crear, orquestar y gestionar sus integraciones; cuando necesita sustituir una arquitectura de punto a punto heredada; o cuando necesita asistencia de gestión de API. Requerido Ambos Sí Sí Sí Con herramientas de procódigo No Sí* Múltiples
\*La activación Shield Platform Encryption cambia ciertos comportamientos, consulte [Consideraciones generales Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obtener más detalles. \*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción. ### Caso de uso: Integración saliente utilizando herramientas de código profesional > Cuando se ganan oportunidades, se debe crear un pedido para los productos asociados en el sistema ERP o de gestión de pedidos de la compañía. **Apex personalizado** Puede crear un desencadenador Apex y un controlador o controladores de desencadenador en la Oportunidad que realizan una llamada al sistema ERP o de gestión de pedidos cuando la etapa de la oportunidad cambia a "Ganada". Tenga en cuenta que si realiza llamadas desde un desencadenador o después de realizar una operación DML, debe utilizar un método anotado como futuro o colocable en cola. Una llamada en un desencadenador mantiene la conexión de la base de datos abierta durante el tiempo de vida de la llamada. Todo el código Apex está vinculado por [Apex Governor y API Limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm), que se revisan de forma continua. **Servicios externos** Si el sistema ERP externo de la compañía o el sistema de gestión de pedidos se definen a través de una especificación OpenAPI, las llamadas a esos servicios que se realizan en el método futuro o el trabajo colocable en cola podrían simplificarse. Los servicios externos registrados se pueden llamar directamente desde Apex sin necesidad de escribir código de placa de caldera. En el ejemplo, la llamada para crear el pedido puede gestionarse por el servicio externo. **MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. MuleSoft Anypoint puede crear API para permitir el acceso de lectura (y/o escritura) a datos para Salesforce y muchos otros sistemas de negocio. Hay [muchos conectores preintegrados disponibles](https://www.mulesoft.com/platform/cloud-connectors) para simplificar la implementación, y las compañías pueden crear y publicar sus propios conectores también. Estas API se pueden implementar en Anypoint con políticas de seguridad flexibles, que admiten la gestión y la gobernanza centralizadas. No hay restricciones en el volumen de transacciones, siempre que la API tenga el tamaño adecuado para su utilización máxima (medida en vCores). ## Datos de sistemas externos en Salesforce (Integración entrante) Para integraciones entrantes en Salesforce, puede considerar diferentes tipos de herramientas: código bajo, código pro o híbrido. Las siguientes secciones proporcionan orientación para cada uno de estos tipos de herramientas y ofrecen soluciones de muestra. - [Herramientas de bajo código para integraciones entrantes](#herramientas-de-código-bajo-para-integraciones-entrantes-en-salesforce) - [Herramientas híbridas para integraciones entrantes](#herramientas-híbridas-para-integraciones-entrantes-en-salesforce) - [Herramientas de código profesional para integraciones entrantes](#herramientas-de-procódigo-para-integraciones-entrantes-en-salesforce) ### Herramientas de código bajo para integraciones entrantes en Salesforce
Directrices Licencia Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación* Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación
Heroku Connect Cuando desea ampliar sus datos con sincronización bidireccional para activar aplicaciones móviles y otras en Heroku, y desea que los datos también se repliquen en Salesforce. Requerido Async Sí Sí No Con herramientas de procódigo Sí Sí, a través de Shield Connect OAuth
Procedimiento de integración de OmniStudio Cuando necesita importar y transformar datos desde fuentes externas sin interacción del usuario. Requerido Ambos Sí Sí Sí Compatibilidad declarativa No Sí Credenciales nombradas
Salesforce Connect / Objetos externos Cuando desea que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo que pueda utilizar protocolos estándar como Odata o GraphQL. Requerido Sync Sí Sí Sí Con herramientas de procódigo No N/A Múltiples
\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción. ### Caso de uso: Integración entrante utilizando herramientas de código bajo > Un contacto se actualiza en el sistema ERP de la organización. Esta información de contacto debe actualizarse en Salesforce. **Heroku Connect** Heroku Connect se utiliza habitualmente para mantener una base de datos Postgres de Heroku y Salesforce sincronizadas. A menos que el sistema ERP utilice Postgres de Heroku como su almacén de transacciones, este caso de uso no es posible. Si utiliza Postgres de Heroku, los cambios realizados en las tablas Postgres se pueden sincronizar con objetos en Salesforce utilizando Heroku Connect. **Procedimiento de integración** de OmniStudio Después de que el sistema ERP actualice el registro de contacto, se puede llamar a un procedimiento de integración de OmniStudio con una acción de carga de asignador de datos y una acción de respuesta a través de la API de REST generada por el asignador de datos. En primer lugar, una acción Carga de asignador de datos envía una carga JSON o XML, que se utiliza para alterar los registros de contacto basándose en un campo Id. externo o a través de una [Clave de inserción](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio). Si una respuesta sencilla en JSON es todo lo que se espera, una Acción de respuesta puede enviar cualquier información relevante desde las acciones anteriores para indicar éxito o fallo. Si el sistema ERP espera una respuesta específica, se puede utilizar una transformación de asignador de datos o una acción de extracción para generar una respuesta JSON o XML con funciones adicionales para incluir declarativamente datos que se generaron en desencadenadores por la actualización de registro de contacto. El principal reto con este escenario es la concurrencia: Múltiples llamadas para actualizar el mismo registro de contacto de forma simultánea provocarán problemas ya que la API existe directamente en Salesforce. **Salesforce Connect / Objetos externos** Salesforce Connect y los objetos externos no se recomiendan para este caso de uso, porque el escenario requiere específicamente la replicación de datos en Salesforce. Si tiene una integración Salesforce Connect preexistente construida en el sistema ERP, puede configurar el conector Odata 4.0 para admitir Captura de datos de cambios externos si el sistema ERP puede admitir Captura de datos de cambios. Además, debe configurar en Salesforce para suscribirse a la transmisión de cambios desde el sistema ERP, utilizando la API Pub/Sub. ### Herramientas híbridas para integraciones entrantes en Salesforce
Directrices Licencia Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación** Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación
Eventos de plataforma Cuando necesita una carga estructurada definida personalizada para cambios casi en tiempo real en Salesforce o un sistema externo. No requerido* Async Sí No Sí Con herramientas de procódigo Sí Sí OAuth
Salesforce Connect / Objetos externos (con adaptadores Apex personalizados) Cuando necesita que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo que no puede utilizar protocolos Odata 2.0/4.0. Requerido Ambos Sí Sí Sí Con herramientas de procódigo No N/A Múltiples
Data 360 Cuando desea datos armonizados desde diferentes orígenes en un solo establecimiento de datos, o desea replicar sus datos desde otras organizaciones de Salesforce o en otros sistemas externos. Data 360 también admite la virtualización para algunas plataformas. Requerido Ambos Sí Sí Sí No Sí Sí Múltiples
\*Se requiere [un complemento](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) para casos de uso de gran volumen. \*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción. ### Caso de uso: Integración entrante utilizando herramientas híbridas > Un contacto se actualiza en el sistema ERP de la organización. Esta información de contacto debe actualizarse en Salesforce. **Eventos de plataforma** El código personalizado en un sistema externo publica un Evento de plataforma cuando se actualiza el registro de contacto en el sistema ERP. Un desencadenador, Proceso o Flujo en Salesforce puede suscribirse al evento de plataforma y actualizar los objetos de Salesforce correspondientes cuando se procesa un evento. El Evento de plataforma puede funcionar simplemente como una señal de que se produjo un cambio en el sistema ERP del cliente sin incluir ningún dato, o puede contener los datos reales necesarios para actualizar el objeto de Salesforce. **Salesforce Connect / Objetos externos (con adaptadores Apex personalizados)** Esta solución no es aplicable en un caso de uso que requiere replicación de datos. Esta solución es aplicable si necesita que los usuarios de Salesforce vean información de un sistema externo que no debe o no puede replicarse en Salesforce, y el sistema externo no puede admitir protocolos estándar como Odata o GraphQL. Consulte Caso de [uso: Integración saliente utilizando herramientas](#caso-de-uso-integración-saliente-utilizando-herramientas-híbridas) híbridas para un caso de uso de ejemplo para un adaptador personalizado Apex. **Datos 360** Cuando se actualiza un contacto en sistemas externos como ERP, las actualizaciones de contacto se pueden sincronizar con Data 360 utilizando conectores listos para su uso o utilizando API y herramientas de procódigo como MuleSoft. También se puede hacer referencia al contacto en Data 360 utilizando un mecanismo de copia cero (disponible con algunas plataformas). Una vez que los datos están disponibles en Data 360, se pueden utilizar diferentes mecanismos de integración de uso inmediato para sincronizar los datos con otras organizaciones de Salesforce. Se puede acceder a los datos por referencia utilizando Data Cloud One. Los datos también se pueden replicar utilizando activaciones y otras API utilizando conectores listos para su uso o con la ayuda de herramientas de procódigo como MuleSoft Anypoint Platform. ### Herramientas de procódigo para integraciones entrantes en Salesforce
Directrices Licencia Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación**** Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación
Servicios web REST y SOAP de Apex personalizados Cuando necesita más funciones que las proporcionadas por los extremos de API nativos como procesamiento de objetos cruzados u otra lógica compleja. No se requiere Ambos Sí Sí Sí Con herramientas de procódigo No Sí*** Múltiples
MuleSoft Anypoint Cuando necesita una única solución unificada de nivel de compañía para crear, orquestar y gestionar sus integraciones; cuando necesita sustituir una arquitectura de punto a punto heredada; o cuando necesita asistencia de gestión de API. Requerido Ambos Sí Sí Sí Con herramientas de procódigo No Sí*** Múltiples
API nativas de Salesforce Cuando necesita más control o tiene un conjunto de habilidades de procódigo para crear integraciones a través de API de REST, API de SOAP, API masiva o API de GraphQL o gRPC. No requerido* Ambos Sí***** Sí Sí Con herramientas de procódigo Sí** Sí*** Múltiples
\*Se aplican [límites y asignaciones](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) de solicitudes de API. \*\*Las API masivas tienen aspectos de comportamiento de reintento y un número de API ofrecen protección _contra reversiones_ a través de la configuración allOrNone (por ejemplo, consulte [Parámetros allOrNone en solicitudes compuestas y de recopilaciones](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm)) \*\*\*Activar Shield Platform Encryption cambia ciertos comportamientos, consulte [Consideraciones generales Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obtener más detalles. \*\*\*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción. \*\*\*\*\*Las API compuestas tienen compatibilidad con múltiples objetos. ### Caso de uso: Integración entrante utilizando herramientas de código profesional > Un contacto se actualiza en el sistema ERP de la organización. Esta información de contacto debe actualizarse en Salesforce. **Servicios web Apex REST y SOAP** personalizados Puede crear un servicio web utilizando código Apex que podría realizar operaciones CRUD (crear, leer, actualizar, eliminar) en el objeto Contacto. Este servicio se invocará a través de SOAP o REST desde el sistema externo (el sistema ERP). **MuleSoft Anypoint** La intención de MuleSoft Anypoint es proporcionar gestión de API de nivel de compañía. MuleSoft Anypoint ofrece un [gran conjunto de conectores preintegrados](https://www.mulesoft.com/platform/cloud-connectors) que puede utilizar para integrar con muchos sistemas ERP incluyendo SAP, Oracle EBS, Oracle ERP y NetSuite. Puede crear un flujo para escuchar eventos en estos sistemas ERP (en este caso, cuando se crea un nuevo contacto). Cuando se inicia el flujo, utiliza el conector de Salesforce para crear un nuevo registro Contacto (o actualizar uno si el contacto ya existe). Además, es posible integrar con otros sistemas si la transacción de replicación implica distribuir el contacto en otros sistemas. Si es necesario, puede utilizar el lenguaje de asignación y transformación (DataWeave) para realizar cálculos y lógica compleja como flujos de información entre múltiples sistemas dispares. La autenticación en estos sistemas se puede realizar a través de muchos mecanismos de autenticación diferentes como Autenticación básica y OAuth, entre otros. No hay restricciones en el volumen de transacciones siempre que el flujo tenga el tamaño adecuado para su utilización máxima (medida en vCores). **API nativas de Salesforce** Cuando (o inmediatamente después) se completa la transacción de actualización en el sistema ERP, puede realizar una operación de alteración en el objeto Contacto a través de la API de SOAP o realizar un [PARCHE](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) en la API de REST de sObjects de Contacto en la organización de Salesforce. ## Integraciones de Salesforce a Salesforce El producto Salesforce to Salesforce alcanzó su fin de vida útil. Salesforce to Salesforce facilitó a los socios que trabajan juntos la tarea de vender y dar asistencia a clientes conjuntos, pero Salesforce invertirá en aportar más innovación a otras herramientas. En adelante, se recomiendan los siguientes enfoques para compartir datos entre organizaciones de Salesforce. ### Herramientas para la integración de datos entre organizaciones de Salesforce
Directrices Costo Cronología Volumen y escala Entrega y mantenimiento Privacidad y seguridad Herramientas para implementar
Cuándo utilizar Licencia adicional Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido) Compatibilidad con múltiples objetos LDV/masa Pruebas e implementación* Depuración Comportamiento de reintento/gestión de errores integrado Puede utilizar con datos cifrados en periodos de inactividad Protocolo de autenticación Código bajo → Código profesional
Heroku Connect Cuando desea ampliar sus datos con sincronización bidireccional entre organizaciones de Salesforce y también activar el acceso a los datos desde aplicaciones móviles y otras que se ejecutan en Heroku Requerido Async Sí Sí No Con herramientas de procódigo Sí Sí, a través de Shield Connect OAuth Código bajo
MuleSoft Anypoint Cuando necesita una única solución unificada de nivel de compañía para crear, orquestar y gestionar sus integraciones; cuando necesita sustituir una arquitectura de punto a punto heredada; o cuando necesita asistencia de gestión de API Requerido Ambos Sí Sí Sí Con herramientas de procódigo No Sí** Múltiples Código Pro
API nativas de Salesforce Cuando Salesforce o Heroku Connect no son una opción o necesita un procesamiento más complejo No se requiere Ambos No Sí Sí Con herramientas de procódigo No Sí** Múltiples Código Pro
Captura de datos Cuando necesita publicar cambios a nivel de registro realizados en Salesforce en un sistema externo y no necesita una carga personalizada. Requerido Async No No Sí Con herramientas de procódigo Sí Sí OAuth
Salesforce Connect con adaptador entre organizaciones Cuando desea que los usuarios en una organización vean o modifiquen registros en una organización diferente sin replicación de datos Requerido Async Sí Sí Sí Con herramientas de procódigo N/A N/A Múltiples Código bajo
Data 360 Cuando desea que los usuarios de una organización vean o modifiquen registros en una organización diferente con datos replicados en Data 360. Requerido Ambos Sí Sí Sí Con herramientas de procódigo Sí Sí Múltiples Híbrido
\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción \*\*La activación Shield Platform Encryption cambia ciertos comportamientos, consulte [Consideraciones generales Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obtener más detalles. Los eventos de _plataforma no son óptimos para integrar datos desde una organización de Salesforce a otra, porque no pueden “escuchar” entre organizaciones para el mismo evento. Apex personalizado tampoco es un enfoque recomendado para este tipo de integración._ ### Caso de uso: Conexión de múltiples organizaciones de Salesforce > Una gran empresa opera entre múltiples unidades de negocio (BU). Cada BU tiene su propia organización de Salesforce. Un único cliente trata con múltiples unidades de negocio de la compañía y, por lo tanto, tiene datos de cuentas y oportunidades en múltiples organizaciones. La compañía necesita acceder a una vista agregada de todos los datos de Cuenta y Oportunidad entre todas las unidades de negocio en una sola organización. _Nota: Todas las soluciones a continuación están diseñadas para la menor cantidad de replicación de datos, de acuerdo con la [Conclusión #1](#comida-para-llevar)._ Los datos de cuentas y oportunidades de **Data 360** de diferentes organizaciones de Salesforce se pueden ingresar en Data 360 utilizando conectores de Salesforce listos para su uso. También se pueden agregar y armonizar (si es necesario). Una vez agregados los datos en Data 360, se puede acceder a ellos en otras organizaciones de Salesforce utilizando Data Cloud One sin replicación de datos. **Heroku Connect** Para la organización individual de cada unidad de negocio, puede utilizar Heroku Connect para sincronizar cambios desde Salesforce en una única base de datos Postgres de Heroku. En este escenario, la sincronización bidireccional no está activada, solo la sincronización desde Salesforce a Postgres. A continuación, en Heroku Connect, puede activar el proveedor de Odata y seleccionar las tablas que desea exponer como objetos externos en la organización de Salesforce donde desea una vista agregada. Desde Salesforce, define una fuente de datos externa que apunta al proveedor de Odata en Heroku. **MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. Se puede configurar una API de MuleSoft Anypoint de modo que lea información de múltiples organizaciones de Salesforce relacionadas utilizando el conector de Salesforce con múltiples conexiones con las organizaciones. El flujo de MuleSoft puede consultar las diferentes organizaciones de Salesforce y devolver una estructura específica mejorada o enriquecida con otra información externa si es necesario. Cuando se invoca la API, realizará todas las llamadas de organización de Salesforce apropiadas (en este ejemplo consultando información de Cuenta y Oportunidad) de modo que los datos puedan procesarse por el consumidor (probablemente una interfaz de usuario). La autenticación en estos sistemas se puede realizar a través de una variedad de mecanismos de autenticación incluyendo autenticación básica y OAuth. No hay restricciones en el volumen de transacciones, siempre que el flujo se haya dimensionado correctamente para su utilización máxima (medida en vCores o Núcleos). Las operaciones de consulta de las **API nativas de Salesforce** se pueden enviar a cada una de las organizaciones de interés, especialmente a través de la API masiva de Salesforce 2.0, que es adecuada para extraer miles de registros de forma eficiente. Puede recuperar los resultados de la consulta de cada organización individualmente y agregarlos con una aplicación personalizada o middleware por requisitos de cliente. **Salesforce Connect con adaptador entre organizaciones** El adaptador entre organizaciones Salesforce Connect no encaja bien en este escenario, ya que las cuentas u oportunidades de organizaciones remotas aparecerán todas en la organización central como objetos _diferentes_. Por ejemplo, no hay forma de agregar un total general para los Importes de todas las Oportunidades entre todas las organizaciones. **Escenario de actualizaciones selectivas entre organizaciones:** Un vendedor que utilice la organización A de Salesforce debe ver y actualizar los datos del caso desde la organización B de Salesforce y agregar comentarios de casos al caso principal en la organización B de Salesforce mientras trabaja en la organización A. Los datos no deben replicarse en la organización A. **Heroku Connect** Puede utilizar el mismo enfoque descrito en el _Escenario de agregación_ de datos anterior. Sin embargo, debe activar CRUD en el objeto externo a través del conector Odata y redactar los cambios de vuelta en Postgres de Heroku. **MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. Puede utilizar el mismo enfoque descrito en el _Escenario de agregación_ de datos anterior. Las **API nativas de Salesforce** utilizan credenciales nombradas e invocan las API nativas de Salesforce para leer y actualizar datos en la organización de Salesforce relacionada. Un componente debe estar diseñado para mostrar los datos. **Salesforce Connect con adaptador entre organizaciones** La capacidad de ver datos en un objeto externo (así como modificar los datos si tiene CRUD activado en el objeto externo) se admite a través del [adaptador entre organizaciones](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5) de Salesforce. Las relaciones también son compatibles entre objetos externos de modo que puede vincular al caso principal en el objeto externo. Sin embargo, la creación de relaciones es un proceso manual hoy en día en el que convierte un tipo de datos existente en un tipo de datos de relación. Además, las optimizaciones realizadas en Service Cloud para trabajar con Casos de forma más efectiva no se transmiten en cascada a la organización remota. Salesforce recomienda encarecidamente probar el adaptador entre organizaciones y evaluar las ventajas de trabajar con objetos externos frente a objetos estándar para su caso de uso. **Sincronización de datos entre organizaciones**: Cuando se actualiza una cuenta para un cliente en una de las organizaciones de Salesforce de la unidad de negocio de la organización, los otros objetos Cuenta de la organización de Salesforce deben actualizarse para mantener la información de cuenta coherente. **Data 360** Data 360 se puede utilizar para la replicación de datos desde una organización a otra organización de Salesforce. Los datos de cuentas de una organización de Salesforce se pueden ingresar en Data 360 utilizando conectores de Salesforce listos para su uso. Podemos utilizar mecanismos de activación de datos como activación por lotes, acciones de datos casi en tiempo real o activaciones basadas en API también para mover los datos de Data 360 a la organización de Salesforce. **Heroku Connect** Puede utilizar el mismo enfoque descrito en el _Escenario de agregación_ de datos anterior. Sin embargo, debe activar la sincronización bidireccional y ya no necesita activar Salesforce Connect ya que la sincronización bidireccional mantendrá todas las organizaciones al día cuando se realicen cambios en la tabla Postgres. **MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. Puede [configurar una aplicación](https://docs.mulesoft.com/design-center/about-designing-a-mule-application) Mule con Flow Designer en MuleSoft Anypoint para escuchar eventos de objetos estándar y personalizados para iniciar un flujo iniciado automáticamente en Salesforce. Cuando se desencadena la aplicación Mule, puede invocar el conector Anypoint para Salesforce para comunicarse con cualquier número de organizaciones de Salesforce. En este caso de uso, cuando se actualiza un registro Cuenta en una organización de Salesforce, la aplicación Mule puede actualizar registros Cuenta en las organizaciones de Salesforce relacionadas. Cada organización de Salesforce relacionada tendría un paso de actualización exclusivo integrado en el flujo de aplicación general en MuleSoft. La autenticación en estos sistemas se puede realizar a través de varios mecanismos de autenticación, incluyendo autenticación básica y OAuth. No hay restricciones en el volumen de transacciones siempre que el flujo se haya dimensionado correctamente para su utilización máxima (medida en vCores o Núcleos). **API nativas de Salesforce** La [API de replicación](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (operaciones getUpdated, getDeleted) podría utilizarse para sincronizar datos entre organizaciones, pero no se recomienda este enfoque. **Salesforce Connect con adaptador entre organizaciones** Puede utilizar flujos desencadenados por registros y objetos externos para mantener algunos datos sincronizados entre organizaciones de Salesforce. Por ejemplo, la actualización de un registro de cuenta en la Organización A desencadena un flujo que luego actualiza el registro coincidente en el objeto externo Cuenta, que escribe esas actualizaciones en el registro de cuenta en la Organización B. Esto requiere el uso adecuado de la semántica de flujos para evitar [transacciones DML mezcladas](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1). Además, tenga en cuenta que las reglas de validación y los flujos en la organización B se desencadenarán del mismo modo que cuando se realicen cambios por nuestras API de REST/SOAP. ## Observaciones finales Tenga en cuenta esta guía y remítase a ella cuando planifique una nueva integración de datos que implique Salesforce. Siempre es una buena idea comprender el alcance completo de las opciones disponibles para usted y cómo pueden ajustarse a su caso de uso específico. ### Dinos lo que piensas Ayúdenos a asegurarse de que estamos publicando lo más relevante para usted. [Realice nuestra encuesta](https://sfdc.co/J0cWb) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. # Interoperabilidad de Data 360 Las compañías a menudo almacenan datos en Salesforce y otros lagos de datos externos (por ejemplo, _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_ o almacenamiento de objetos como _Amazon S3_). El silo de datos entre múltiples sistemas crea un reto para las compañías que desean aprovechar el valor completo de sus datos para potenciar experiencias dirigidas por IA. Salesforce _Data 360_ es la capa de inteligencia fundamental que cada agente de IA Agentforce utiliza para acceder al contexto correcto en el momento correcto. Los arquitectos que trabajan para reunir datos entre múltiples lagos de datos se enfrentan a decisiones arquitectónicas clave sobre cómo integrar mejor esos datos. _Data 360_ proporciona múltiples opciones para la integración de datos, cada una ofreciendo varios pros y contras. ## Descripción general de guía Esta guía proporciona un marco de trabajo para evaluar qué patrón se ajusta mejor a sus requisitos de latencia, costo, capacidad de ampliación, gobernanza y complejidad al integrar datos, ayudándole a elegir cuándo utilizar el ingreso de datos, la federación de datos Cero copia o un enfoque híbrido. La guía también le ayudará a seleccionar entre diferentes métodos de ingreso de datos y federación de datos, cada uno de los cuales satisface una necesidad diferente. La integración de casas de lago de datos externas con _Data 360_ requiere considerar cuidadosamente las ventajas entre la actualización de datos, la gobernanza y la eficiencia de las oportunidades en curso. Por ejemplo, el uso de consultas en vivo de federación de datos Cero copia maximiza la actualización de los datos pero puede reducir la eficiencia de las oportunidades en curso a medida que más datos se mueven por la red. Para la mayoría de las implementaciones del mundo real, la combinación del ingreso y la federación en un ecosistema de casas de lago de múltiples nubes es la ruta óptima. Este enfoque híbrido garantiza una arquitectura ampliable, gobernada e interoperable que admite cargas de trabajo operativas de baja latencia (por ejemplo, personalización en tiempo real y detección de fraudes) y cargas de trabajo analíticas (por ejemplo, creación de reportes regulatorios y análisis de tendencias históricas). Esta guía le ayuda a determinar cómo navegar por estas compensaciones utilizando una estrategia apropiada. ## Conclusiones clave - **El ingreso de** datos copia datos en Salesforce _Data 360_ y crea modelos de datos canónicos gobernados. Esto es ideal para cuando necesita: - **Cree un Customer 360 integral.** Esto le permite unificar y transformar orígenes dispares en un único perfil de confianza. - **Cumplir con el estricto cumplimiento normativo.** Esto le permite crear una copia auditable y centralizada de modo que el acceso a los datos y el linaje puedan controlarse estrechamente. - **Federación de copia cero** consulta fuentes externas en tiempo real sin duplicación, lo que permite la personalización en tiempo real, tableros en vivo e incorporación rápida de fuentes. Este enfoque proporciona dos opciones principales, pero hay ventajas que deben equilibrarse: - **Consulta en vivo:** Utilice esto para análisis interactivos y tableros de datos en tiempo real que viven en plataformas de datos externas (por ejemplo, _Snowflake_, _BigQuery_, _Redshift_ o _Databricks_). Esto ayuda a evitar la duplicación de datos lenta y costosa enviando el procesamiento de consultas al sistema de origen y devolviendo solo los resultados necesarios. Este enfoque está optimizado para consultas poco frecuentes o ad-hoc donde la actualización es crítica. Es adecuado para cargas de trabajo de baja _consulta por segundo (QPS)_ (los costos de consulta pueden aumentar significativamente con un QPS alto). - **Almacenamiento en caché (Consulta acelerada):** Utilice esto para consultas de datos frecuentes que no cambian a menudo. Las consultas aceleradas mantienen una caché local que se actualiza a intervalos configurables (15 minutos a 7 días), lo que reduce las coincidencias de origen repetidas. Este enfoque equilibra el desempeño y el costo del tablero, la segmentación y las cargas de trabajo de BI donde los resultados ligeramente obsoletos son aceptables. Esto no es adecuado para la toma de decisiones de subsegundos. - **Federación de archivos:** Utilice esto para el procesamiento por lotes a gran escala y el entrenamiento de modelos de IA para datos en el lago de datos de su nube (por ejemplo, _S3_ o _ADLS_). Este enfoque evita el ingreso lento y costoso consultando directamente archivos en formatos de tabla abierta, lo que desbloquea conjuntos de datos ETL masivos y cargas de trabajo de ciencia de datos. - Los **modelos híbridos** combinan el ingreso para _Perfiles unificados_ con la federación para mayor frescura, lo que admite la implicación de OmniCanal, acciones dirigidas por Agentforce y entrenamiento de IA/ML. ### Consideraciones importantes - **Emplear una arquitectura híbrida.** La mezcla de ingreso y federación de datos es a menudo necesaria. - Utilice _Ingreso de datos_ en datos críticos para modelos de datos canónicos y gobernanza principal. - Utilice _Copia cero_ para el resto de la federación de datos para mantener la actualización y minimizar la carga operativa de la creación y el mantenimiento de oportunidades en curso de ingreso de datos. - **La frecuencia de ingreso de datos importa.** Seleccione la frecuencia basándose en el valor de negocio, las necesidades de latencia y la complejidad operativa. - Utilice _tiempo real_ para flujos de trabajo urgentes (por ejemplo, personalización, tableros en vivo y acciones Agentforce). - Utilice _Casi en tiempo real_ para procesos de urgencia moderada (por ejemplo, campañas y reportes operativos). - Utilice lotes para conjuntos de datos históricos o de baja velocidad. - **Haga coincidir patrones de federación con latencia y desempeño.** Seleccione la opción que mejor se ajuste a sus patrones de acceso y requisitos de frescura, desempeño y costo. - Utilice _Live Query_ para tableros operativos y personalización en tiempo real donde la baja latencia es crítica. - Utilice el almacenamiento en _caché (Consulta acelerada)_ cuando las consultas sean frecuentes y los resultados ligeramente obsoletos sean aceptables, lo que ayuda a equilibrar el desempeño y el costo. - Utilice _Federación de archivos_ para análisis a gran escala y con gran rendimiento o cargas de trabajo por lotes, ideales para conjuntos de datos históricos o menos urgentes. - **Alinear la gobernanza con los requisitos de residencia de datos.** - Utilice la _ingesta_ cuando la gobernanza centralizada sea crítica. - Utilice la _federación_ cuando la gobernanza descentralizada sea aceptable, mientras aplica una gobernanza estricta en el origen externo. - Utilice _Copia cero_ con respecto a políticas a nivel de origen (por ejemplo, _seguridad a nivel_ de filas y enmascaramiento de datos). - **Priorice el ingreso para flujos de trabajo de alto valor.** Aplique el ingreso de forma selectiva a procesos críticos (por ejemplo, resolución de identidad, creación de reportes regulatorios y activación operativa). - **El costo y la complejidad dirigen las decisiones.** El ingreso en tiempo real puede ser costoso y complejo. Por eso es importante que los arquitectos sopesen el costo de incorporar, almacenar y transformar datos con el costo de consultarlos directamente a través de _Copia cero_. La selección del patrón de integración correcto (_Ingreso de datos_, _Copia cero_ o un enfoque _híbrido_) afecta directamente a la latencia, la gobernanza, la eficiencia operativa y el costo entre plataformas multinube. Esta decisión determina cómo se entregan perspectivas en tiempo real, activación dirigida por IA e implicación personalizada de forma fiable y a escala. ## Comparación de productos Esta tabla compara los patrones de _ingesta de datos_ y _copia cero_ en Salesforce _Data 360_, centrándose en funciones, compensaciones y beneficios, así como casos de uso y resultados de negocio. Utilice esto como referencia para diseñar plataformas de datos híbridas de múltiples nubes que equilibran desempeño, costo y cumplimiento.
Tipo de patrón Modo/herramienta Beneficios Consideraciones Resultados
Ingreso de datos En tiempo real:
  • Ingreso de latencia por debajo del segundo a través de las API de ingreso con compatibilidad de CDC.
  • Canalizaciones de transmisión continua.
  • Proporciona perspectivas inmediatas
  • Abarca casos de uso operativos y de personalización de baja latencia
  • Admite flujos de trabajo dirigidos por eventos
  • Alto costo
  • Arquitectura compleja
  • Requisitos del sistema de origen de baja latencia
  • Las fuentes de gran volumen pueden causar una transmisión excesiva, lo que lleva a oportunidades en curso saturadas
  • intensivo de E/S
  • Los campos selectivos y el filtrado pueden ayudar a reducir los gastos generales
Agentforce:
  • Alertas de fraude en tiempo real, personalización minorista y alertas operativas
Analytics:
  • Tableros de subsegundos y monitoreo de KPI
Cumplimiento:
  • Actualizaciones continuas de registros de clientes para flujos de trabajo regulados
Transmisión:
  • Ingreso de microlotes cada 1 a 3 minutos a través de conectores nativos
  • Equilibra el costo frente a la frescura
  • Cuenta con una arquitectura más sencilla que en tiempo real
  • Admite actualizaciones incrementales
  • Leve latencia
  • Puede no ser adecuado para decisiones críticas de subsegundos
  • El tamaño de lote afecta a la memoria/cómputo
  • E/S moderada
  • Adecuado para patrones de actualización predecibles y repetitivos
  • La agregación con ventanas puede ayudar a reducir la carga de procesamiento
Agentforce:
  • Desencadenadores de campaña oportunos y participación casi en vivo
Analytics:
  • Motores de recomendaciones y tableros casi en vivo
Cumplimiento:
  • Actualizaciones frecuentes con capacidad de auditoría
Lote:
  • Proporciona cargas de gran volumen programadas a través de conectores o API.
  • Admite almacenamiento de objetos y oportunidades en curso de ETL/ELT.
  • Admite la rentabilidad para conjuntos de datos masivos
  • Cuenta con una implementación sencilla
  • Proporciona fiabilidad para análisis históricos
  • Latencia de datos
  • Inadecuado para operaciones urgentes
  • intensivo de E/S durante los plazos de carga
  • El rendimiento de red puede convertirse en un cuello de botella para archivos de gran tamaño
  • Adecuado para flujos de trabajo de agregación histórica o creación de reportes regulados
Agentforce:
  • Tickets de asistencia de TI (Jira/ServiceNow) y flujos de trabajo agregados
Analytics:
  • Análisis histórico y evaluación de tendencias
Cumplimiento:
  • Creación de reportes normativos y agregación de datos de pacientes/reclamaciones
Zero Copy Consulta en vivo:
  • Proporciona consultas directas en sistemas externos y esquemas en lectura sin duplicación de datos
  • Proporciona la máxima frescura
  • Cuenta con una carga de almacenamiento mínima
  • Admite perspectivas operativas en tiempo real
  • Dependiendo del desempeño de origen
  • Un alto volumen de consultas puede afectar a la latencia
  • Adecuado para consultas con distribución y agregación de predicados para minimizar las E/S
  • Evitar el uso de consultas sin filtrar en conjuntos de datos masivos
Agentforce:
  • Flujos de trabajo dinámicos que se adaptan a la actividad en vivo
Analytics:
  • Tableros operativos y creación de reportes en vivo
Cumplimiento:
  • Respeta la seguridad a nivel de filas y el enmascaramiento en el origen
Consulta acelerada (almacenamiento en caché):
  • Proporciona copias locales en caché para consultas federadas que son configurables de 15 minutos a 7 días.
  • Proporciona una ejecución de consultas optimizada
  • Reduce la latencia
  • Cuenta con costos más bajos que las consultas en vivo repetitivas
  • Mejora el desempeño para patrones de acceso frecuentes
  • Gestión de caché requerida
  • El estado depende de los intervalos de caché
  • Adecuado para consultas de alta frecuencia
  • No es adecuado para la decisión de subsegundos
  • La actualización incremental solo admite alteraciones; los registros eliminados no se eliminan de la caché.
  • Requiere una actualización completa manual de forma periódica para mantener la caché sincronizada con el origen
Agentforce:
  • Mediciones de implicación preagregadas para una decisión rápida
Analytics:
  • Tableros de BI, segmentación y creación de reportes analíticos
Cumplimiento:
  • Tableros regulados de forma coherente con registros de auditoría
Federación de archivos:
  • Proporciona acceso directo a grandes conjuntos de datos históricos en establecimientos de objetos o lagos (por ejemplo, S3, Iceberg, Google BigQuery y Redshift).
  • Procesa conjuntos de datos a gran escala
  • Requiere almacenamiento mínimo en Data 360
  • Admite cargas de trabajo de IA/ML
  • Solo lectura
  • El desempeño de las consultas depende del rendimiento del sistema externo
  • Adecuado para trabajos intensivos de rendimiento por lotes
  • No apto para tableros en tiempo real
Agentforce:
  • No es típico (cargado por lotes)
Analytics:
  • Capacitación de ML/IA, análisis histórico y creación de reportes a escala de petabytes
Cumplimiento:
  • Gobierna el acceso a conjuntos de datos externos sin duplicación
## Patrones de integración de Data 360 Existen tres patrones de integración principales para Data 360: ingreso de datos, federación de datos sin copia y un enfoque híbrido. ### Ingreso de datos Con _Ingreso de datos_, los datos se copian físicamente en _Data 360_ y se rigen completamente, a diferencia de _Copia cero_ donde los datos permanecen en el origen. En otras palabras, la computación para transformaciones se produce en _Data 360_, que proporciona una gobernanza y auditoría centralizadas. #### Casos de uso de ingreso de datos Utilice _Ingreso de datos_ para almacenar conjuntos de datos gobernados canónicos en Salesforce _Data 360_ para el cumplimiento y el control operativo. Utilice el ingreso cuando se requiera control completo, auditoría y trazabilidad. El ingreso de datos es ideal para flujos de trabajo regulados o de alto valor donde la computación centralizada y la gobernanza son fundamentales. El ingreso es adecuado para crear una base de confianza para la resolución de identidad, la creación de reportes regulatorios, flujos de trabajo dirigidos por IA de misión crítica y la implicación de clientes. Descripción general de ingreso de datos #### Métodos de ingreso de datos Los métodos de _ingesta de datos_ pueden variar, dependiendo del conector que utilice para ingresar sus datos. Algunos conectores ofrecen una variedad de métodos de ingreso, mientras que otros solo funcionan en modo por lotes o transmisión. Para obtener una lista completa de conectores de _Data 360_ y métodos disponibles, consulte [Data 360: Integraciones y conectores](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5). - **En tiempo real:** - Proporciona un ingreso de subsegundos utilizando _Captura de datos (CDC)_ - Adecuado para flujos de trabajo urgentes (por ejemplo, detección de fraude, personalización y tableros operativos) - Cuenta con transformaciones distribuidas y agregaciones en _Data 360_, lo que ayuda a reducir las E/S descendentes y optimizar el uso de computación - Admite el uso de CDC incrementales para minimizar la reorganización de datos - **Transmisión:** - Proporciona ingesta cada 1-3 minutos en pequeños incrementos - Equilibra la frescura y el costo - Adecuado para orquestación de campañas, implicación casi en vivo y creación de reportes operativos - Admite el uso de microlotes para controlar picos de E/S - Agrega datos en el origen (si es posible) para reducir volúmenes de transferencia y optimizar el almacenamiento - **Lote (Cargas programadas):** - Proporciona el ingreso periódico de grandes conjuntos de datos (por ejemplo, cada hora, cada día y cada semana) - Proporciona rentabilidad y fiabilidad para conjuntos de datos históricos, creación de reportes reguladores y casos de uso de cumplimiento - Garantiza que la localidad de cálculo está en la misma región que el almacenamiento de origen para mejorar el desempeño y optimizar los costos #### Libro de jugadas de arquitecto - **Casos de uso de ingreso de datos:** - **Generar perfiles unificados Customer 360.** Cree una única fuente de verdad para atributos e identidades de clientes. - **Mantenga conjuntos de datos de cumplimiento normativo.** Aplique la gobernanza, el linaje y la capacidad de auditoría para datos confidenciales. - **Centralice la orquestación de campañas.** Asegúrese de que marketing, ventas y servicio funcionan desde conjuntos de datos coherentes y de confianza. - **Prácticas de diseño:** - Acomode el ingreso por lotes para necesidades históricas o tolerantes a baja latencia (por ejemplo, creación de reportes de archivo o instantáneas periódicas). - Utilice las API de transmisión o CDC para mantener la actualización para flujos de trabajo operativos y de personalización para garantizar actualizaciones casi en tiempo real. - Controle el almacenamiento y calcule el crecimiento aplicando cargas incrementales para optimizar el costo y la eficiencia (en vez de volver a cargar conjuntos de datos completos). - Alinee las oportunidades en curso de ingreso con la localidad de cálculo y el procesamiento incremental para reducir la E/S de red. - Aplique transformaciones dentro de _Data 360_ para evitar mover datos sin procesar innecesariamente. - **Consideraciones de costos:** - **Ingreso en tiempo real** tiene los costos de computación y oportunidades en curso más altos, que pueden justificarse para flujos de trabajo de alto valor y urgentes (por ejemplo, personalización, tableros operativos o acciones dirigidas por Agentforce). - **Ingreso de transmisión** tiene costos de computación y almacenamiento moderados, que pueden ser adecuados para actualizaciones frecuentes que pueden tolerar ligeros retrasos (por ejemplo, orquestación de campañas o creación de reportes operativos). - **Ingreso por lotes** tiene costos de computación más bajos y almacenamiento predecible, lo que es adecuado para conjuntos de datos históricos o actualizaciones de baja frecuencia. El ingreso de datos por lotes desde organizaciones de Salesforce utilizando ciertos conectores es gratuito. - **Modo de actualización** Le permite seleccionar el modo _de actualización incremental_, que reduce el ingreso total y calcula los costos. En Salesforce, recomendamos utilizar _actualización incremental_ siempre que sea posible para optimizar la eficiencia entre todos los tipos de ingreso. - El **costo** también se ve afectado por el volumen de E/S desde el origen a _Data 360_. La optimización de tamaños de lote, particiones y alineación regional reduce los costos de transferencia y mejora el desempeño. - **Escenarios de industria:** - **Finanzas:** Los conjuntos de datos de ingreso son obligatorios para _conocer a su cliente (KYC)_, _antiblanqueo de dinero_ y detección de fraude donde la capacidad de auditoría y el cumplimiento no son negociables. - **Cuidados sanitarios:** Utilice el ingreso para la resolución de identidad de pacientes y registros compatibles con HIPAA, lo que permite vistas seguras y unificadas. - **Retail:** Consolide datos de _puntos de venta_, comercio electrónico y programas de fidelidad en perfiles unificados para segmentación y personalización. - **Telecom:** Apoye la prevención de abandonos y los análisis de uso con datos de suscriptor gobernados canónicos. #### Criterios de decisión de método de ingreso de datos | Función | Ingreso en tiempo real | Ingreso de transmisión | Ingestión por lotes | | :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Latencia y frescura** | Cuenta con ingreso de latencia de subsegundos a través de las API de ingreso con compatibilidad de _Captura de datos_. Proporciona oportunidades en curso de transmisión continua. Adecuado para casos de uso operativos de baja latencia. | Incluye el ingreso de microlotes cada 1 a 3 minutos a través de conectores nativos. Admite actualizaciones incrementales. Se espera una ligera latencia. | Se espera latencia de datos. Permite cargas de gran volumen programadas. Cuenta con ingesta periódica (por hora, diariamente y semanalmente). No es adecuado para operaciones urgentes. | | **Casos de uso principales** | Ideal para casos de uso operativos y de personalización de baja latencia. Utilizar para flujos de trabajo urgentes. Admite flujos de trabajo dirigidos por eventos. Utilice alertas de fraude en tiempo real y alertas operativas. | Adecuado para procesos de urgencia moderada. Utilizar para orquestación de campañas, implicación casi en vivo y creación de reportes operativos. Utilizar para desencadenadores de campaña oportunos. | Rentable para conjuntos de datos masivos. Fiable para análisis históricos. Utilizar para flujos de trabajo de agregación histórica o creación de reportes regulados. Adecuado para conjuntos de datos históricos o de baja velocidad. | | **Complejidad arquitectónica y E/S** | Incluye arquitectura compleja y de alto costo. Requiere sistemas de origen de baja latencia. E/S intensiva. Los orígenes de gran volumen pueden causar oportunidades en curso saturadas. | Cuenta con una arquitectura más sencilla que en tiempo real. E/S es moderada. Adecuado para patrones de actualización repetidos predecibles. El tamaño de lote afecta a la memoria y el cálculo. | Fácil de implementar. intensivo de E/S durante los plazos de carga. El rendimiento de red puede convertirse en un cuello de botella para lotes grandes. | | **Consideraciones de costos** | Incluye los costos de computación y oportunidades en curso más altos. Justificable solo para flujos de trabajo de alto valor y urgentes. | Incluye costos de computación y almacenamiento moderados. Proporciona un enfoque de costo frente a frescura equilibrado. Adecuado para actualizaciones frecuentes que pueden tolerar ligeros retrasos. | Las funciones reducen los costos de computación y el almacenamiento predecible. Recomendado para conjuntos de datos históricos o actualizaciones de baja frecuencia. El ingreso a través de oportunidades en curso internas de Salesforce es gratuito. | | **Prácticas de diseño** | Utilice CDC incrementales para minimizar la reorganización de datos. Filtre y utilice campos selectivos para reducir los gastos generales. | Utilice microlotes para controlar picos de E/S. Considere la agregación con ventanas para reducir la carga de procesamiento. | Utilizar para creación de reportes de archivo o instantáneas periódicas. Asegúrese de que la localidad de cálculo está en la misma región que el almacenamiento de origen para la optimización de costos. | ### Federación de datos de copia cero #### Cero casos de uso de copia Utilice _Copia cero_ para la consulta en tiempo real de sistemas externos sin duplicación de datos para permitir la agilidad, la actualización y el acceso ampliable a conjuntos de datos grandes o transitorios. Es adecuado para tableros en vivo, análisis exploratorios, entrenamiento de modelos de IA/ML e implicación de clientes en tiempo real directamente a través de Salesforce _Data 360_. Descripción general de federación de datos de copia cero #### Métodos de copia cero Al utilizar _Copia cero_, los arquitectos deben elegir entre tres métodos de federación de datos disponibles, cada uno de los cuales ofrece sus propias ventajas entre frescura, desempeño y costo. - **Consulta en vivo** - Ejecuta consultas directamente en sistemas externos (por ejemplo, _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_, etc.) sin duplicación de datos. - Minimiza el movimiento de datos en la red y reduce la E/S en el cálculo de Salesforce _Data 360_, que es óptimo cuando se pueden empujar predicados y agregaciones hacia abajo. - Adecuado para perspectivas en tiempo real y tableros operativos de baja latencia. - Dependiendo del desempeño del sistema externo. - **Almacenamiento en caché (Consulta acelerada)** - Almacena temporalmente copias en caché de datos federados en Salesforce _Data 360_. - Reduce los costos y la latencia de consultas repetidas para conjuntos de datos a los que se accede con frecuencia con duración configurable (minutos a días). - Los datos no se copian de forma permanente ni se rigen completamente, de modo que la actualización se gestiona a través de actualizaciones programadas desde el origen. - _La actualización incremental_ solo admite alteraciones. Los registros eliminados no se eliminan de la caché. - Realice una actualización completa periódicamente para asegurarse de que la caché permanece sincronizada con el origen. - **Nota:** El conector _de Snowflake_ admite la función _Descargar_, que mejora los índices de aceleración utilizando un depósito de preparación iniciado por Snowflake. Esto está activado de forma predeterminada, pero se puede desactivar modificando la conexión. - **Federación de archivos** - Proporciona acceso directo de solo lectura a conjuntos de datos a gran escala en establecimientos de objetos (por ejemplo, _S3_ y _GCS_ con _Iceberg_). - Adecuado para cargas de trabajo de IA/ML, análisis históricos y creación de reportes a escala de petabytes sin mover datos. - El desempeño de las consultas depende en gran medida del formato del objeto, la partición y la E/S de red. Las exploraciones de gran tamaño pueden generar E/S sustanciales si no están optimizadas. #### Libro de jugadas de arquitecto - **Casos de uso** - La **personalización en tiempo real y flujos de trabajo adaptativos** entregan ofertas dinámicas, recomendaciones y siguientes mejores acciones a medida que cambian los comportamientos de los clientes. - Los **tableros en vivo y** los análisis operativos potencian los tableros clave de negocio y los indicadores clave de desempeño directamente desde almacenes externos. - El entrenamiento de modelos de **IA/ML con grandes conjuntos de datos externos** aprovecha los datos a escala de petabytes de lagos de datos y almacenes sin moverlos a través de Federación de archivos. - **Escenarios industriales** - **Retail/Media:** Active recomendaciones personalizadas e implicación de clientes en tiempo real federando datos de interacciones de contenido o transmisiones de clics. - **Finanzas:** Ejecute la detección de fraudes y el puntuaje de riesgos casi en tiempo real consultando almacenes externos sin duplicar datos confidenciales. - **Tech/Enterprise:** Admita la creación de reportes entre nubes, tableros de servicio de TI y análisis operativos cuando los conjuntos de datos residen en múltiples sistemas. - **Prácticas de diseño** - **Consulta en vivo** - Utilizar para consultas de alta QPS y baja latencia cuando la actualización es crítica. - Envíe predicados y agregaciones al sistema externo para reducir la reorganización de datos en la red. - Evite consultas que exploran innecesariamente volúmenes de datos masivos. - Considere la poda de particiones y filtros en su lugar. - **Federación de archivos** - Acceda a conjuntos de datos a escala de petabytes en establecimientos de objetos sin ingreso. - Minimice la latencia y los costos de salida manteniendo el almacenamiento de objetos en la misma región de Cloud que el cálculo de Salesforce. - Utilice formatos particionados y columnares (Parquet/ORC) y filtros de distribución para reducir la transferencia de E/S y red. - Aproveche la distribución de consultas y predicados para filtrar y agregar datos en el origen, lo que reduce el movimiento de datos. - Evite el acceso a datos entre regiones, a menos que sea absolutamente necesario, porque aumenta la E/S, la latencia y los costos. - **Almacenamiento en caché (Consulta acelerada)** - Almacenar en caché conjuntos de datos a los que se accede frecuentemente para equilibrar el costo y el desempeño. - Configure intervalos de actualización para equilibrar la actualización frente al costo de consulta. - **Cumplimiento:** Aplique la regulación en el origen aprovechando la _seguridad a nivel_ de filas y enmascarando políticas directamente en sistemas federados. - Estas son algunas mejores prácticas para el enmascaramiento y el RLS uniforme entre plataformas: - **Utilice un Id. de compañía centralizado.** Asigne usuarios y entidades en Salesforce _Data 360_ a un identificador de compañía único y centralizado que se corresponda con identidades en sistemas externos. - **Alinee Políticas de seguridad.** Asegúrese de que las políticas de RLS y enmascaramiento en sistemas federados se aplican basándose en la identidad asignada. Esto mantiene el cumplimiento al consultar datos externos. - **Estandarizar esquemas de identidad.** Mantenga atributos de identidad coherentes (email, Id. de usuario, Id. de cliente, etc.) entre todos los orígenes de datos para evitar desajustes e infracciones de acceso. - **Consideraciones de costos** - **Consulta en vivo:** En el modelo de pago por consulta, los costos se acumulan en el cálculo de casas de lago externas, lo que puede provocar picos con un alto QPS. Esto es adecuado para casos de uso críticos de frescura donde el valor es superior a la variabilidad de costos. - **Consulta acelerada (almacenamiento en caché):** Este método reduce el costo de la consulta (en comparación con _Consulta en vivo)_ reduciendo las visitas al sistema de origen; sin embargo, se suma a los costos de ingreso de datos por lotes para rellenar y actualizar la caché. Esto es adecuado para conjuntos de datos de acceso frecuente. - **Federación de archivos:** Esta es la opción de almacenamiento más económica como datos en Almacén de objetos; sin embargo, los costos de consulta dependen del tamaño del archivo, la partición y la poda. Esto es adecuado para datos históricos o masivos a escala de petabytes. #### Criterios de decisión de método de copia cero | Punto de decisión | Consulta en vivo | Almacenamiento en caché (Consulta acelerada) | Federación de archivos | | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Ubicación de origen** de datos | Casas de lago de datos externas (por ejemplo, _Snowflake_, _Google BigQuery_, _Redshift_ y _Databricks_) | Casas de lago de datos externas (por ejemplo, _Snowflake_, _Google BigQuery_, _Redshift_ y _Databricks_) | Establecimientos de objetos o lagos de datos de nube (por ejemplo, _S3_, _ADLS_ y _GCS_), que a menudo utilizan formatos de tabla abierta como _Iceberg_. | | **Propósito/Caso de uso** | Adecuado para análisis interactivo y tableros en tiempo real. Adecuado para la personalización en tiempo real y flujos de trabajo dinámicos. | Adecuado para cuando las consultas son frecuentes, pero los resultados ligeramente obsoletos son aceptables. Adecuado para tableros de BI y segmentación. | Adecuado para el procesamiento por lotes a gran escala y el entrenamiento de modelos de IA/ML. Adecuado para análisis históricos y creación de reportes a escala de petabytes. | | **Frescura/Latencia** | Proporciona la máxima frescura Ejecuta consultas directamente en tiempo real. Admite decisiones por subsegundos cuando el sistema de origen está optimizado para consultas de baja latencia con distribución de predicados efectiva. | Utilizar cuando los resultados ligeramente obsoletos son aceptables. La actualización depende del intervalo de caché, que es configurable de 15 minutos a 7 días. | Adecuado para trabajos intensivos de rendimiento y por lotes. No es adecuado para tableros en tiempo real. | | **Patrón de acceso** | Adecuado para consultas infrecuentes o ad-hoc donde la actualización es crítica y el volumen de consultas es bajo. Los costos se disparan significativamente a un QPS alto, de modo que es importante evaluar el almacenamiento en caché (Consulta acelerada) cuando la frecuencia de consulta es alta. | Adecuado para escenarios de lectura de alta frecuencia. Mejora el desempeño para patrones de acceso frecuentes. | Proporciona acceso *de solo lectura*. Adecuado para conjuntos de datos a escala de petabytes sin ingreso. | | **Controladores de desempeño** | Muy dependiente del desempeño del sistema de origen externo. Adecuado para cuando los predicados y las agregaciones se pueden enviar al origen. | Reduce la latencia en comparación con consultas en vivo repetidas. El desempeño depende de la gestión de caché y los intervalos. | El desempeño depende en gran medida del formato del objeto, la partición y el rendimiento del sistema externo. Utilice formatos particionados y de columnas (Parquet/ORC). | | **Consecuencias de costos** | Este es un modelo de pago por consulta, de modo que los costos se acumulan en cálculos de casas de lago externas. Es rentable para consultas poco frecuentes, pero los gastos pueden aumentar con un alto volumen de QPS. | El costo es inferior a las consultas en vivo repetidas. Reduce la necesidad de consultar repetidamente el origen externo, pero agrega almacenamiento en caché y sobrecarga de actualización. | Esta es la opción de almacenamiento más económica. Para configuraciones de AWS de la misma región y la misma nube (por ejemplo, _S3_ en EE.UU.-Este-1 con un arrendatario de _Data Cloud_ que también está en EE.UU.-Este-1), los créditos no se consumen para las filas a las que se accede. Las configuraciones entre regiones o entre nubes (por ejemplo, _Azure_, _GCS_ o diferentes regiones _de AWS_) generan consumo de crédito para las filas a las que se accede. Los costos de consulta también dependen del tamaño del archivo, la partición y la optimización de distribución de predicados. | | **Consideración clave** | Evite consultas sin filtrar que exploran volúmenes de datos masivos innecesariamente. | Este enfoque requiere gestión de caché. No es adecuado para la decisión de subsegundos. | El desempeño de las consultas se basa en gran medida en la optimización a través de particiones y distribución de predicados. | ### Enfoque híbrido Las arquitecturas híbridas permiten a los arquitectos anclar conjuntos de datos críticos en _Data 360_ para una gobernanza centralizada al tiempo que aprovechan las consultas federadas para mayor frescura, menor duplicación y acceso ampliable a conjuntos de datos externos de gran tamaño. Este enfoque equilibra las E/S, calcula la localidad, el costo y los requisitos de cumplimiento. #### Casos de uso híbridos Utilice un enfoque híbrido para una gobernanza equilibrada, frescura y eficiencia operativa combinando el ingreso de datos y la copia cero para entregar perspectivas con capacidad de acción en tiempo real. Utilice el ingreso para conjuntos de datos regulados de alto valor donde se requiere trazabilidad, RLS y enmascaramiento, y la federación para conjuntos de datos efímeros o de gran volumen donde la actualización y el desempeño son clave. Descripción general de enfoque híbrido #### Libro de jugadas de arquitecto - **Casos de uso** - **Participación de OmniCanal:** Combine datos históricos de clientes con comportamiento en tiempo real para entregar experiencias coherentes y contextuales. - **Oportunidades en curso de IA/ML:** Entrene modelos en conjuntos de datos canónicos depurados mientras los enriquece con señales sin procesar o en tiempo real procedentes de fuentes externas. - **Necesita cumplimiento y agilidad mixtos:** Aplique una regulación estricta para datos confidenciales y una federación para la agilidad operativa. - **Escenarios industriales** - **Retail:** Utilice _el ingreso_ para la resolución de identidad y la unificación de perfiles, así como la _federación_ para ofertas y personalización en tiempo real. - **Cuidados sanitarios:** Mantenga registros de pacientes dorados a través _del ingreso_ mientras utiliza la _federación en_ transmisiones de dispositivos IoT y datos de sensores para contexto inmediato. - **Servicios financieros:** Ingrese datos regulados en un lago regulado por el cumplimiento mientras utiliza _la federación_ para consultas de detección de fraude externo y monitoreo de riesgos. - **Prácticas de diseño** - **Ancle la gobernanza con el ingreso:** Ingrese datos de alto valor o regulados en modelos canónicos para garantizar Trust y cumplimiento. - **Utilizar Federation for Freshness:** Permite a las casas de lago externas proporcionar acceso a datos en tiempo real o a gran escala sin duplicación. - **Equilibrar costo frente a desempeño:** Perfil de cargas de trabajo para determinar cuándo utilizar la _ingesta_ frente a la _federación_, lo que minimiza los costos de almacenamiento y consulta innecesarios. - **Aplicar gobernanza por capas:** Aplique la regulación centralizada para datos ingresados mientras aprovecha los controles de seguridad de sistemas federados (por ejemplo, RLS y enmascaramiento). - **Nota:** Cuando está diseñando oportunidades en curso híbridas, es importante garantizar el ingreso incremental para conjuntos de datos históricos y distribuir agregaciones o filtros a orígenes federados para optimizar la E/S y calcular el uso. - **Consideraciones de costos** - Sopese el costo total frente al desempeño combinando _el ingreso_ de datos críticos o de cumplimiento con _la federación_ cuando se necesita actualización. - Tenga en cuenta las E/S y calcule la distribución al mezclar _el ingreso_ y _la federación_. Para reducir el costo de computar consultas repetidas en sistemas de origen, utilice el almacenamiento en caché (Consulta acelerada) para conjuntos de datos federados de alta lectura y acceso frecuente. - Utilice esta regla para guiar la decisión de ingreso frente a federación: cuando se accede a los datos con frecuencia pero cambia con poca frecuencia, _Consulta acelerada_ suele ser más rentable. Sin embargo, cuando los datos cambian con frecuencia (en relación con la frecuencia de acceso), _Live Query_ o _el ingreso_ es más apropiado. Estos son algunos ejemplos de costos: - **La aceleración gana:** Un tablero creado a partir de 1 millón de registros y actualizado diariamente con ~10.000 cambios se visualiza 20 veces al día. Los costos _de aceleración_ equivalen a aproximadamente ~600 créditos/mes frente a ~4.200 créditos/mes para _Consultas en vivo_. - **Live Query gana:** Segmentos que se publican 20 veces al día utilizando datos que cambian cada 30 minutos. Las _Consultas en vivo_ cuestan aproximadamente ~4.200 créditos/mes frente a ~28.800 créditos/mes para _la aceleración_ con esta frecuencia de actualización. ## Guía de decisiones de casos de uso Echemos un vistazo con más detalle a algunos arquetipos comunes que ilustran cómo aplicar esta lógica. - **El arquetipo "Fuente única de la verdad": Centralizar y gobernar** - **Escenario:** Necesita crear perfiles de _Customer 360_ unificados que cumplan los requisitos para toda su compañía global. Los datos provienen de una docena de sistemas diferentes, deben cumplir con las estrictas leyes de _RGPD_ y _CCPA_, y servirán como la fuente de la verdad para todas las interacciones de marketing y servicio. - **Patrón recomendado:** **Ingreso de datos.** La prioridad aquí es la gobernanza, Trust y Control. Ingresar los datos en _Data 360_ es la única forma de crear un perfil canónico completamente auditable que esté aislado de los sistemas de origen. - **El arquetipo "Perspectivas en tiempo real": Analizar sin moverse** - **Escenario:** Su equipo de ciencias de datos necesita ejecutar consultas exploratorias en una tabla de transacciones masiva y en constante actualización en _Snowflake_. Al mismo tiempo, su equipo ejecutivo desea un tablero de _BI_ en vivo que funcione con esos mismos datos. Mover petabytes de datos diariamente es lento y costoso. - **Patrón recomendado:** **Zero Copy Federation.** La prioridad aquí es la velocidad, la agilidad y la rentabilidad a escala. _Copia cero_ le permite aprovechar la potencia de su almacén de datos existente para consultas en tiempo real sin la carga y la latencia de la duplicación de datos. - **El arquetipo "Inteligencia híbrida": Gobernar el núcleo, federar el borde** - **Escenario:** Desea enriquecer sus perfiles de clientes gobernados e ingresados con señales de comportamiento en tiempo real (por ejemplo, clics de sitios web) desde un lago de datos. Necesita la estabilidad del perfil principal pero la inmediatez de los datos en vivo para potenciar la personalización en el momento. - **Patrón recomendado:** **Un enfoque híbrido.** Utilice _Ingreso de datos_ para crear un núcleo estable y regulado para sus datos de clientes. Utilice _Copia cero_ para federar los datos volátiles de "borde" en tiempo real, y luego unirlos entre sí en el momento de la consulta para una vista completa al segundo. ## El camino a seguir La estrategia de datos de compañía ya no se centra en la elección de un patrón de integración único: se trata de diseñar flexibilidad controlada dentro de un ecosistema de datos interoperable. El enfoque correcto asigna cada sistema de origen al patrón que mejor se ajuste a sus requisitos de frescura, gobernanza, costo y acceso: - Ingrese conjuntos de datos regulados de misión crítica en Salesforce _Data Cloud_ para el cumplimiento, la resolución de identidad y los flujos de trabajo operativos. - Genere datos a través de _Copia cero_ para análisis en vivo, exploratorios y dirigidos por IA sin duplicar el almacenamiento. - Aplicar _almacenamiento en caché (Consulta acelerada)_ para reducir la carga del sistema de origen y el consumo de crédito cuando la frecuencia de consulta es alta y la frecuencia de cambio de datos es baja Salesforce _Data 360_ en _Hyperforce_ ofrece capacidad de ampliación y resistencia de múltiples regiones. Su casa de lago abierto con tablas de _Iceberg_ permite la separación de cálculos y la interoperabilidad con plataformas como _Snowflake_, _Databricks_ y _S3 Iceberg, que_ forma la columna vertebral de un ecosistema de datos multinube verdaderamente interoperable. A medida que evolucionan los ecosistemas de datos, debemos equilibrar continuamente la frescura, el costo, el desempeño y el cumplimiento para mantener la agilidad arquitectónica. Por eso es importante preparar su plataforma para el futuro unificando datos ingresados y gobernados con acceso federado. Esto permite la inteligencia en tiempo real, la activación de IA y la personalización a escala de compañía entre nubes, regiones y dominios de negocio. Tenga en cuenta que las soluciones únicas no se adaptan a la mayoría de los negocios. La estrategia óptima asigna el patrón correcto al controlador de negocio correcto. ## Acerca de los autores **Yugandhar Bora** es un Arquitecto de Ingeniería de Software en Salesforce que se especializa en arquitectura de datos dentro de la plataforma Aplicaciones de datos e inteligencia. Lidera iniciativas de la _Junta de_ Revisión de la Arquitectura Empresarial (EARB) que se centran en la gobernanza de datos y modelos de datos unificados, mientras que también contribuye a soluciones de aprovisionamiento de plataforma automatizadas. **Jan Fernando** es Arquitecto Principal de la _Oficina del Arquitecto Jefe (OCA)_ de Salesforce, que se incorporó a Salesforce en 2012\. Aporta una gran experiencia de su época en el ecosistema de startups. Antes de unirse a la OCA, pasó más de una década en la organización _Plataforma_, donde lideró varias transformaciones tecnológicas clave. # Primeros pasos con las guías de decisiones de Data 360 Esta sección proporciona directrices prácticas para tomar decisiones arquitectónicas críticas acerca de Salesforce Data 360, incluyendo estrategias de aprovisionamiento, conectividad de múltiples organizaciones y patrones de integración. Utilice estas guías para diseñar e implementar arquitecturas de datos efectivas que unifiquen datos de clientes y activen funciones con tecnología de IA. --- ## Aprovisionamiento de Data 360 El [aprovisionamiento de datos](/docs/architect/es-mx/decision-guides/guide/data-360-provisioning) 360 cubre decisiones fundamentales al aprovisionar Salesforce Data 360: - **Selección de organización**: Decida si aprovisionar Data 360 en una organización de producción existente o crear una organización dedicada, teniendo en cuenta la gobernanza, el cumplimiento y el tiempo hasta el valor. - **Estrategia multiorganización**: Seleccione entre múltiples instancias independientes de Data 360 o utilice Data Cloud One para unificar múltiples organizaciones de Salesforce, equilibrando la autonomía, el cumplimiento y el costo. - **Data Cloud One Architecture**: Active múltiples organizaciones de compañía para compartir una única instancia de Data 360 con gobernanza centralizada, colaboración de metadatos y paridad de funciones entre organizaciones. - **Compartición de datos entre organizaciones de Data 360**: Utilice la colaboración de datos sin copia entre instancias independientes para el cumplimiento regional, la colaboración de unidades de negocio o tableros ejecutivos federados. - **Consideraciones de aprovisionamiento**: Tenga en cuenta la residencia de datos, los modelos de gobernanza, la latencia, la complejidad de la integración, el costo y la preparación de la IA para implementaciones de toda la compañía. Ayuda a los arquitectos a diseñar estrategias de aprovisionamiento que garantizan la simplicidad, la coherencia de la compañía, el cumplimiento y la capacidad de ampliación para Customer 360, la IA y la innovación entre plataformas. --- ## Interoperabilidad de Data 360 La [interoperabilidad de Data 360](/docs/architect/es-mx/decision-guides/guide/data-360-interoperability) proporciona un marco de trabajo para integrar Data 360 con plataformas externas y lagos de datos: - **Patrones de ingreso**: de datos Ingreso en tiempo real, transmisión y por lotes para crear conjuntos de datos canónicos gobernados ideales para Customer 360, cumplimiento y gobernanza centralizada. - **Federación de datos de copia cero**: Consulta en vivo, Consulta acelerada (almacenamiento en caché) y Federación de archivos para acceder a sistemas externos en tiempo real sin duplicaciones, lo que permite la personalización, tableros y cargas de trabajo de IA/ML. - **Enfoque híbrido**: Combine el ingreso gobernado para conjuntos de datos principales con una federación de copia cero para mayor frescura y capacidad de ampliación, lo que admite la implicación de OmniCanal, acciones dirigidas por Agentforce y análisis de negocio. - **Marco de decisiones**: Evalúe las compensaciones en latencia, costo, escalabilidad, gobernanza y complejidad para seleccionar el patrón de integración correcto por origen de datos. - **Libros de jugadas de arquitecto**: Directrices específicas de la industria, prácticas de diseño y consideraciones de costos para escenarios de finanzas, cuidados sanitarios, minoristas y telecomunicaciones. Guía a los arquitectos en el equilibrio de la frescura de los datos, la gobernanza y la eficiencia de las oportunidades en curso para crear arquitecturas de datos ampliables, interoperables y listas para la IA que admiten cargas de trabajo operativas y analíticas. # Procesamiento asíncrono Utilice esta guía para elegir el enfoque de procesamiento asíncrono de Salesforce correcto para cada caso de uso. ## Descripción general de guía Esta guía le ayudará a evaluar el enfoque correcto para sus requisitos de procesamiento asíncrono en Salesforce Platform. Explica cada enfoque, detallando los puntos fuertes y las limitaciones de cada uno. La mayoría de los enfoques están alineados con una función de producto, pero algunos enfoques utilizan múltiples funciones en coordinación. La guía incluye casos de uso para resaltar cuándo utilizar cada enfoque. El procesamiento asíncrono proporciona dos beneficios principales para su arquitectura. En primer lugar, aumenta la capacidad de ampliación porque los procesos asíncronos tienen límites reguladores más altos. En segundo lugar, las solicitudes asíncronas se ejecutan en sus propios hilos de modo que los usuarios pueden realizar otro trabajo mientras las tareas asíncronas se ejecutan en segundo plano. Tenga en cuenta que esta guía se centra exclusivamente en la selección de una tecnología de procesamiento asíncrono en Salesforce Platform. Otros recursos para ayudar a su proceso de decisión se enumeran en la [sección Recursos](#recursos). ## Productos en ámbito para esta guía
Plataforma Salesforce Salesforce Lightning Platform es una plataforma integral dirigida por IA que unifica empleados, agentes de IA autónomos, datos de la compañía y aplicaciones en un único sistema de confianza para mejorar la productividad y la experiencia del cliente. Permite la creación de una "compañía agencia" conectando aplicaciones Customer 360, Data Cloud y Slack para la automatización de extremo a extremo.
Este documento no cubre tecnologías en otros ecosistemas como MuleSoft, Informatica, Commerce Cloud, Tableau y Marketing Cloud. ## Comida para llevar - **Antes de utilizar el procesamiento asíncrono, asegúrese de que sus casos de uso se ajustan al patrón.** Los patrones asíncronos no tienen SLA, están sujetos a múltiples mecanismos reguladores, pueden tener límites de capacidad definidos basándose en licencias y pueden causar retrasos de procesamiento debido a la naturaleza finita de los recursos asignados a infraestructura asíncrona en Salesforce Platform. Tenga en cuenta estas limitaciones cuando utilice el procesamiento asíncrono en escenarios donde un usuario requiere una respuesta del sistema antes de poder continuar con su trabajo. - **El procesamiento asíncrono con Salesforce no es una solución para necesidades de ampliación ilimitadas.** Salesforce Platform no se amplía infinitamente y los patrones asíncronos están sujetos a limitaciones. El procesamiento asíncrono utiliza hilos, que contienen la información contextual que una CPU necesita para ejecutar una transmisión de instrucciones. Las cadenas pueden ejecutarse en paralelo. El número de hilos disponibles en cualquier CPU es limitado, de modo que la plataforma tiene mecanismos establecidos para utilizar sus hilos disponibles de la forma más eficiente posible. El [mecanismo de control](/docs/architect/es-mx/fundamentals/guide/async-fundamentals#control-de-flujo) de flujo de la plataforma evita que las organizaciones consuman demasiados hilos y afecten negativamente a otras organizaciones. El [algoritmo de uso](/docs/architect/es-mx/fundamentals/guide/async-fundamentals#uso-justo) justo de la plataforma también controla el número de hilos que una organización tiene disponibles para cada tipo de mensaje concreto. - **Tenga en cuenta eventos que pueden causar cargas extremas.** Cuando diseñe procesos asíncronos, asegúrese de que pueden gestionar de forma predecible picos y pausas de carga de trabajo. Considere cómo gestiona su implementación eventos inesperados, como cortes de energía, y diseñe salvaguardas que mitiguen la pérdida de datos o la pérdida de funciones. ## Comparación de productos Esta tabla describe las herramientas disponibles para el procesamiento asíncrono con Salesforce. Consulte esta tabla para revisar las características principales de cada herramienta durante su proceso de toma de decisiones. Consulte [Utilizar casos](#casos-de-uso) y [puntos de decisión](#puntos-de-decisión) para obtener ayuda para elegir las herramientas correctas para su arquitectura.
Enfoque Descripción Habilidades requeridas Licencias y límites
Apex colocable en cola Utilizar para procesos que implican operaciones de base de datos de larga ejecución o llamadas de servicio web externo. Apex colocable en cola ofrece funciones como Id. de trabajo, compatibilidad para tipos no primitivos y encadenamiento de trabajos. Código pro El número de licencias puede aumentar los límites.
Apex por lotes Cree procesos complejos y de larga ejecución que implican millones de registros dividiendo su conjunto de registros y procesándolo en partes gestionables. Código pro El número de licencias puede aumentar los límites.
Apex programado Ejecute Apex a una hora programada definida por una expresión cron. Aunque el acto de programar Apex mediante la expresión cron es un proceso asíncrono, el código subyacente se ejecuta de forma síncrona cuando se inicia el trabajo. Código pro El número de licencias puede aumentar los límites.
Llamadas de continuación Apex Ejecute llamadas desde métodos Apex ejecutándose en un contexto de transacción síncrono. Código pro No
Ruta asíncrona (Flujos desencadenados por registro) Ejecute una operación que desea ejecutar en su propio tiempo. Evite errores DML mixtos que se producen cuando actualiza un valor en un registro relacionado que no forma parte del registro que desencadenó un flujo. Código bajo El número y el tipo de licencias pueden aumentar los límites.
Ruta programada (Flujos después de confirmar) Ejecute a una hora programada dinámicamente después de un evento desencadenante, como cuando se crea, se actualiza o se elimina un registro. Código bajo El número y el tipo de licencias pueden aumentar los límites.
Flujos programados Ejecute un flujo en segundo plano a una hora especificada y con una frecuencia repetida (diariamente, semanalmente o una vez) para realizar acciones en un lote de registros. Código bajo El número y el tipo de licencias pueden aumentar los límites.
Desencadenadores de eventos de plataforma Acople Salesforce libremente con sistemas externos y comuníquese entre componentes asíncronos en Salesforce Platform. Código bajo + código profesional Se requiere una licencia complementaria para casos de uso de eventos de plataforma de gran volumen
Captura de datos Capture y procese eventos de cambio de forma asíncrona después de confirmar la transacción de la base de datos. Código pro Se requiere una licencia complementaria para ampliar por encima de la asignación de línea base.
API masiva Inserte, actualice, altere, consulte o elimine muchos registros de forma asíncrona y procese los resultados más adelante. Código pro Hay límites.
Acciones Lightning Permita a las páginas Lightning interactuar con el servidor sin forzar a los usuarios a actualizar completamente la página. Código bajo No
## Puntos de decisión Esta tabla contiene una descripción general de puntos a tener en cuenta cuando decida qué herramienta asíncrona utilizar.
Habilidades requeridas Algunas de las herramientas descritas en esta guía requieren código, mientras que otras se pueden configurar de forma declarativa. Cuando considere sus opciones, piense en los conjuntos de habilidades que tienen los miembros de su equipo. Recuerde que incluso si los desarrolladores están disponibles para su implementación inicial (a través de un socio de implementación, por ejemplo), es posible que tenga que modificar sus soluciones en el futuro. Si su equipo de mantenimiento carece de desarrolladores, una opción de código bajo puede ajustarse mejor.
Tipo de límites de plataforma aplicados Determine el tipo de límites que se aplican a la ejecución. Cuando diseñe sus soluciones, piense cuidadosamente en cómo el volumen y la frecuencia de las transacciones contarán en los límites reguladores para el enfoque elegido cada día. Calcule el número de ejecuciones que se producirán cada día. Asegúrese de que los valores calculados recaen dentro de los límites asociados con sus herramientas seleccionadas.
Latencia Determine con qué rapidez estarán disponibles los resultados del procesamiento en la plataforma. Para algunos enfoques, los cambios serán casi inmediatos, mientras que para otros pueden ser minutos u horas.
## Casos de uso Cuando selecciona una herramienta para el procesamiento asíncrono, primero evalúe los requisitos de su organización y los recursos disponibles. Su objetivo es seleccionar la herramienta o las herramientas que minimizan los costos de implementación y mantenimiento, pero aún garantizan la escalabilidad y minimizan su probabilidad de limitar las infracciones. Este objetivo depende de las consideraciones técnicas descritas anteriormente, así como de la composición de su equipo. Considere un proceso de pedido asíncrono en Salesforce. Cuando se guarda un pedido, desencadena un mensaje a un sistema de gestión de almacén externo con instrucciones especiales sobre cómo empaquetar y enviar un artículo. El usuario que realiza el pedido no necesita una respuesta inmediata del sistema de gestión de almacenes, de modo que la solicitud se puede enviar de forma asíncrona. El procesamiento asíncrono permite al usuario continuar su trabajo sin esperar una respuesta. Para este caso de uso, puede considerar implementar con Apex. Este enfoque solo funcionará si tiene desarrolladores Apex en su equipo que puedan mantener su solución de pro-código. De lo contrario, un enfoque declarativo tiene más sentido. Además, tenga en cuenta que diferentes conjuntos de [límites se](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) aplican a diferentes herramientas. Esta tabla enumera casos de uso comunes en la columna más a la izquierda, seguidos de una descripción. La columna _Primera opción_ proporciona el enfoque más habitual utilizado para satisfacer dicho caso de uso, junto con la justificación del enfoque Primera opción. Utilice esto como un punto de inicio en su análisis: el enfoque Primera opción puede tener limitaciones que no funcionarán para su caso de uso.
Caso de uso Descripción Enfoque de primera opción Justificación
Procesamiento por lotes de alto desempeño Cualquier automatización que debe procesar miles o millones de registros de forma eficiente Apex por lotes Apex por lotes proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.
Trabajo de limpieza de datos Un trabajo que se ejecuta de forma rutinaria, o bajo demanda, que limpia datos. Los ejemplos incluyen la desduplicación, la verificación de direcciones o la consolidación de datos. Apex por lotes Apex por lotes proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.
Trabajo de acumulación nocturno Trabajo que calcula datos de acumulación al final de un día hábil. Apex por lotes Apex por lotes proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.
Lógica desencadenada por registro Ejecute lógica en respuesta a una actualización de registro. Varía Consulte nuestra guía de decisiones complementarias, Automatización de registros de eventos desencadenados. Incluye un árbol de decisiones para casos de uso asíncronos, incluyendo Apex colocable en cola, Apex por lotes, Apex programado, Flujo programado, Flujos de ruta asíncronos y Captura de datos de cambios.
Actualizaciones en cascada a través de un gráfico de objeto Permite que la acción de guardado de un usuario se complete rápidamente, aplazando la ejecución de actualizaciones en cascada a otros objetos de forma asíncrona. Apex colocable en cola Apex colocable en cola tiene potentes funciones de encadenamiento que permiten a la lógica dividir una cadena de actualizaciones en una serie de transacciones asíncronas.
Procesamiento programado específico de registro Automatización en una fecha futura dinámica específica del registro (por ejemplo, 3 días antes de una fecha de cierre). Flujo con una ruta programada Las rutas programadas proporcionan una solidez única a Flujo, ya que la plataforma gestiona automáticamente la programación, cancelación y reprogramación de estas rutas si cambian los datos del registro.
Invocación de múltiples servicios externos lentos en paralelo Durante una ejecución síncrona, se invocan múltiples servicios externos en paralelo para optimizar el tiempo de ejecución general. Llamadas de continuación de Apex Permitir que múltiples llamadas de ejecución lenta se ejecuten en paralelo minimiza el tiempo total para completar el trabajo.
Migración de datos de registros desde un sistema externo Mueva grandes cantidades de registros a Salesforce Platform desde un sistema externo. Un proceso puntual o programado regularmente. API masiva Este es el enfoque más eficiente y orientado a límites para la migración de datos.
Ejecutar lógica adicional en un sistema externo Patrón de activación y olvido de notificar a un sistema externo de un evento en la plataforma, permitiendo luego a ese sistema procesar el evento de forma asíncrona. Eventos de plataforma o Captura de datos Un modelo pub-sub funciona mejor aquí y permite al sistema externo procesar el evento cuando está listo. Consulte Arquitectura dirigida por eventos para obtener más detalles sobre este patrón.
La tabla Casos de uso es una guía hacia el enfoque más adecuado para cada caso de uso. Sin embargo, deberá validar cuán bien se ajusta la tecnología First Choice a las necesidades específicas de su caso de uso. En particular, determine si el enfoque elegido puede cumplir los límites reguladores para su organización. Una vez que haya identificado un enfoque candidato para su caso de uso, la [Guía de fundamentos](/docs/architect/es-mx/fundamentals/guide/async-fundamentals) de procesamiento asíncrono puede ayudarle a examinar completamente la solución. ## Recursos Estos recursos adicionales pueden ayudarle con su proceso de decisión: - Profundice en cada una de las tecnologías asíncronas de plataforma: [Fundamentos de procesamiento asíncrono](/docs/architect/es-mx/fundamentals/guide/async-fundamentals) - Selección entre Apex y Flow para desencadenadores de registros: [Automatización de eventos desencadenados por registros](/docs/architect/es-mx/decision-guides/guide/record-triggered) - Información sobre patrones de integración asíncronos: [Arquitectura dirigida por eventos](/docs/architect/es-mx/decision-guides/guide/event-driven)