# 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
![]() |
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. |
| 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. |
**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.
- **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.
- **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 |
**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 | ✅ | ✅ |
| 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 |
| 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. |
| 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. |
| 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 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. |
| Punto de decisión | Directrices |
|---|---|
| Notificaciones casi en tiempo real | Los 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 paralelo | Patrones 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 volumen | Los 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 volumen | Los 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 sistemas | Aunque 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 dispositivos | Los 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 IoT | Debido 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ón | Los 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. |
| Punto de decisión | Directrices/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 respuestas | Cualquier 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 frecuencia | Si 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? |
| Patrón | Casi en tiempo real | Copiar mensaje exclusivo | Entrega de garantía | Reducir el tamaño de mensajes | Transformar datos |
|---|---|---|---|---|---|
| Publicar / Suscribir | ✓ | ✓ | ✓ | ||
| Fanout | ✓ | ✓ | ✓ | ||
| Mensajes pasados | ✓ | ✓ | ✓ | ✓ | |
| Transmisión | ✓ | ✓ | ✓ | ||
| Colocación en cola | ✓ | ✓ | ✓ |
| Herramienta | Descripción | Habilidades requeridas | |
|---|---|---|---|
| MuleSoft | Plataforma Anypoint | Plataforma que activa la integración de datos utilizando capas de API. | Código pro |
| Conector Salesforce Pub/Sub | API 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 Connector | Conector 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 Connector | Conector para mover datos entre Apache Kafka y aplicaciones y servicios de negocio. | Código pro | |
| Conector de consola Anypoint de MuleSoft | Un conector para corredores de eventos PubSub+ de Solace con integración de API nativa utilizando el SDK de Java JCSMP | Código pro | |
| MuleSoft Anypoint MQ Connector | Un 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 Connector | Una extensión MuleSoft que cumple el protocolo MQTT (Message Queing Telemetry Transport). | Código pro | |
| Conector AMQP de Mulsoft Anypoint | Un 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 MQ | 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 | |
| Transmisiones de datos de MuleSoft Anypoint | Marco de trabajo disponible en MuleSoft Anypoint para publicar y suscribirse a datos de transmisión. | Código pro | |
| Plataforma Salesforce | Apache Kafka on Heroku | Complemento de Heroku que proporciona Apache Kafka como un servicio con integración de plataforma completa en la plataforma Heroku. | Código pro |
| Captura de datos | Registro 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 salientes | Acciones que envían mensajes XML a extremos externos cuando se actualizan valores de campo en Salesforce. | Código bajo | |
| Eventos de plataforma | Mensajes seguros y ampliables que contienen datos de eventos personalizados. | Código bajo a código profesional | |
| API Pub/Sub | API 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 eventos | Activa 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 | |
#### Herramientas relevantes para el patrón Publicar/Suscribir
| Comportamiento y flujo de eventos | Consideraciones sobre la carga | ||||||
|---|---|---|---|---|---|---|---|
| Herramientas disponibles | Habilidades requeridas | Publicar vía | Suscribirse a través | Periodo de reproducción | Estructura de carga | Límites de carga | |
| MuleSoft | Plataforma Anypoint | Código pro | API | API | Como está configurado | Usuario definido | Ninguna |
| Conector Salesforce Pub/Sub | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint JMS Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint Apache Kafka Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Conector de consola Anypoint de MuleSoft | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQ Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQTT Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Conector AMQP de Mulsoft Anypoint | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| API dirigida por eventos de MuleSoft Anypoint (ASync) | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQ | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Plataforma Salesforce | Apache Kafka on Heroku | Código pro | API, registrar cambios en Postgres de Heroku | N/A | 1-6 semanas | Usuario definido | Usuario definido |
| Captura de datos | Código bajo a código profesional | Cambios de registro | Apex, API, componentes web Lightning (LWC) | 3 días | Predefinido | 1 MB | |
| Mensajes salientes* | Código bajo | Reglas de flujo y flujo de trabajo | N/A | 24 horas | Usuario definido | 100 notificaciones por mensaje | |
| Eventos de plataforma | Código bajo a código profesional | API, Apex, Flujo | Apex, API, Flow, LWC | 3 días | Usuario definido | 1 MB | |
| API Pub/Sub | Código pro | API o API Pub/Sub, Apex, Flujo | API Pub/Sub | 3 días | Usuario definido | 1 MB | |
| Retransmisiones de eventos** | Código bajo | Eventos de plataforma, Captura de datos de cambios | API | 3 días | Usuario definido | 1 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 | |||||||
#### Herramientas relevantes para el patrón Fanout
| Comportamiento y flujo de eventos | Consideraciones sobre la carga | ||||||
|---|---|---|---|---|---|---|---|
| Herramientas disponibles | Habilidades requeridas | Publicar vía | Suscribirse a través | Periodo de reproducción | Estructura de carga | Límites de carga | |
| MuleSoft | MuleSoft Anypoint JMS Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna |
| Conector Salesforce Pub/Sub | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint Apache Kafka Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Conector de consola Anypoint de MuleSoft | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQ Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQTT Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Conector AMQP de Mulsoft Anypoint | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQ | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Plataforma Salesforce | Apache Kafka on Heroku | Código pro | API, registrar cambios en Postgres de Heroku | N/A | 1-6 semanas | Usuario definido | Usuario definido |
| Captura de datos | Código bajo a código profesional | Cambios de registro | Apex, API, componentes web Lightning (LWC) | 3 días | Predefinido | 1 MB | |
| Eventos de plataforma | Código bajo a código profesional | API, Apex, Flujo | Apex, API, Flow, LWC | 3 días | Usuario definido | 1 MB | |
| API Pub/Sub | Código pro | API Pub/Sub o Apex, API, Flujo | API Pub/Sub | 3 días | Usuario definido | 1 MB | |
| Retransmisiones de eventos* | Código bajo | Eventos de plataforma, Captura de datos de cambios | API | 3 días | Usuario definido | 1 MB | |
| *Las retransmisiones de eventos solo envían datos a AWS Eventbridge | |||||||
#### Herramientas relevantes para el patrón de mensajes pasados
| Comportamiento y flujo de eventos | Consideraciones sobre la carga | ||||||
|---|---|---|---|---|---|---|---|
| Herramientas disponibles | Habilidades requeridas | Publicar vía | Suscribirse a través | Periodo de reproducción | Estructura de carga | Límites de carga | |
| MuleSoft | MuleSoft Anypoint Apache Kafka Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna |
| Conector Salesforce Pub/Sub | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Plataforma Salesforce | Apache Kafka on Heroku | Código pro | API, registrar cambios en Postgres de Heroku | N/A | 1-6 semanas | Usuario definido | Usuario definido |
| Captura de datos | Código bajo a código profesional | Cambios de registro | Apex, API, componentes web Lightning (LWC) | 3 días | Predefinido | 1 MB | |
| Eventos de plataforma | Código bajo a código profesional | API, Apex, Flujo | Apex, API, Flow, LWC | 3 días | Usuario definido | 1 MB | |
| API Pub/Sub | Código pro | API o API Pub/Sub, flujo Apex | API Pub/Sub | 3 días | Usuario definido | 1 MB | |
| Retransmisiones de eventos* | Código bajo | Eventos de plataforma, Captura de datos de cambios | API | 3 días | Usuario definido | 1 MB | |
| *Las retransmisiones de eventos solo envían datos a AWS Eventbridge | |||||||
#### Herramientas relevantes para el patrón de transmisión
| Comportamiento y flujo de eventos | Consideraciones sobre la carga | ||||||
|---|---|---|---|---|---|---|---|
| Herramientas disponibles | Habilidades requeridas | Publicar vía | Suscribirse a través | Periodo de reproducción | Estructura de carga | Límites de carga | |
| MuleSoft | Transmisiones de datos de MuleSoft Anypoint | Código pro | API | API | Como está configurado | Usuario definido | Ninguna |
| Conector Salesforce Pub/Sub | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint Apache Kafka Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Plataforma Salesforce | Apache Kafka on Heroku | Código pro | API, registrar cambios en Postgres de Heroku | N/A | 1-6 semanas | Usuario definido | Usuario definido |
| API Pub/Sub | Código pro | API o API Pub/Sub, flujo Apex | API Pub/Sub | 3 días | Usuario definido | 1 MB | |
#### Herramientas relevantes para el patrón de cola
| Comportamiento y flujo de eventos | Consideraciones sobre la carga | ||||||
|---|---|---|---|---|---|---|---|
| Herramientas disponibles | Habilidades requeridas | Publicar vía | Suscribirse a través | Periodo de reproducción | Estructura de carga | Límites de carga | |
| MuleSoft | MuleSoft Anypoint MQ | Código pro | API | API | Como está configurado | Usuario definido | Ninguna |
| Conector Salesforce Pub/Sub | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint Apache Kafka Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQ Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| MuleSoft Anypoint MQTT Connector | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Conector AMQP de Mulsoft Anypoint | Código pro | API | API | Como está configurado | Usuario definido | Ninguna | |
| Plataforma Salesforce | Apache Kafka on Heroku | Código pro | API, registrar cambios en Postgres de Heroku | N/A | 1-6 semanas | Usuario definido | Usuario definido |
| Captura de datos | Código bajo a código profesional | Cambios de registro | Apex, API, componentes web Lightning (LWC) | 3 días | Predefinido | 1 MB | |
| Eventos de plataforma | Código bajo a código profesional | API, Apex, Flujo | Apex, API, Flow, LWC | 3 días | Usuario definido | 1 MB | |
| API Pub/Sub | Código pro | API o API Pub/Sub, Apex, Flujo | API Pub/Sub | 3 días | Usuario definido | 1 MB | |
| Retransmisiones de eventos* | Código bajo | Eventos de plataforma, Captura de datos de cambios | API | 3 días | Usuario definido | 1 MB | |
| *Las retransmisiones de eventos solo envían datos a AWS Eventbridge | |||||||
| 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. |
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 |
| 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. |
| 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. |
### 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.
#### 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:
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.
## Recursos
| Apex | Flujo | Operaciones |
|---|---|---|
| Agentforce | Automatización tradicional | Integración |
|---|---|---|
| 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. |
| 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 |
| 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. |
| 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 |
| 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. | |||||||||||||
| 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 |
| 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 |
| 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 | |||||||
| 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 | ||
| 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. | |||
| 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 | ||||||
| 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 | ||
| 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í. | |||
| 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 | ||
| 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 | ||||
| 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. | |||||
| Á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)? |
| 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í |
| 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. | ||||||||||
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| Tipo de patrón | Modo/herramienta | Beneficios | Consideraciones | Resultados |
|---|---|---|---|---|
| Ingreso de datos |
En tiempo real:
|
|
|
Agentforce:
|
Transmisión:
|
|
|
Agentforce:
|
|
Lote:
|
|
|
Agentforce:
|
|
| Zero Copy |
Consulta en vivo:
|
|
|
Agentforce:
|
Consulta acelerada (almacenamiento en caché):
|
|
|
Agentforce:
|
|
Federación de archivos:
|
|
|
Agentforce:
|
#### 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_.
#### 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.
#### 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
| 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. |
| 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 |
| 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. |
| 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. |